This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
With MySQL on Linux we have an Entity called POG with a table called POG. We don’t see problems with this during normal use but the designer seems unable to cope with the case-sensitivity issue that arises from our need to use the QuoteIdentifiers config option. When updating the database from the designer, it determines that a change needs to be applied to the table but when it applies that change it fails because it uses the table name ‘Pog’ LightSpeed version: 5 and 3.1 but I don’t think it used to happen in 2. Similar problems are supposedly solved by setting the “table name” property on the Entity in the designer so I’ve tried that but it has no effect. I have also verified that the following attribute is applied to the POG entity in the designer generated cs file: [Table("POG")] What am I doing wrong? |
|
|
It doesn't sound like you are doing anything wrong but that behaviour also doesn't sound quite right - from what you have described the casing on the table name and the entity are the same? Is that correct or is there a casing difference on the entity which is why you have set the table name? If there is a casing difference does it work correctly if you adjust the entity casing to match the table? And if not can you send through a copy of the your model definition for that entity and the create table statement so I can try and reproduce this here?
|
|
|
Hi Jeremy, Thanks for your quick reply (I've been on leave for a couple of days so apologies for the slow response). Yes the casing on the table name and entity are the same (both all uppercase) so I tried setting the table name in case being explicit helped the situation. I'll send an email through to support at your domain with the definition and create table statement attached. Let me know if it doesn't arrive / if there's a better way for me to get the info to you. Thanks, Chris |
|
|
Thanks Chris, I have received the email and am having a look into this - hopefully I will be able to repro this and then look into whats causing the issue. Will let you know once I have been able to set up a repro environment and have a look into this further.
|
|
|
Hi, This is still happening with a recent v5 nightly and since we're currently concentrating on updating our data model, this problem has become more urgent for us. Did you have a chance to set up a repro environment and look into it? We've now seen the problem against the following recent database server setup (although I'm not sure how much of the issue is really down to the server):
The platform we found the problem on earlier this year was a slightly older version of CentOS and MySQL 5.5. We'd like to start using the LightSpeed migrations feature and I'm guessing that this problem will be present in that as well as the designer but either way I'm a bit cautious of starting our migration project off on a base configuration that isn't even working properly with the standard designer. Thanks, Chris PS: In case it was a hangover from any previously fixed bugs, I just searched the entire .lsmodel file and found only references to the upper case "POG", no "Pog" references exist. |
|
|
Sorry! No I didnt have any luck with tracking this down previously and I must admit it fell off the radar. Ill try and set up a new environment based on the configuration above tomorrow and let you know if I can repro it.
|
|
|
Just a quick update to let you know Ive built a repro environment for this now so Ill be looking into a fix.
|
|
|
After investigating whats going on is that when we perform the database update we initially construct a snapshot of the current database model to diff against. When building up that model we extract the relevant entity representations based on the tables in the database as per whats in the current model (e.g. If you have an entity called POG, we build up a new representation of that entity based on whats in the database). In doing this we use the appropriate table name if defined to find that table. However once we build up the entity we use different rules for naming it, in particular we look to apply a CLR camel case style name for consistency around naming. This is the crux of the problem - we do want to apply this type of naming by default, however it mucks things up for the subsequent update. We are not able to make any changes here, because this is working as intended for our default case, however there is a mechanism for you to change this behaviour which will resolve the problem. What you need to do is to implement a custom designer naming strategy which will give you control over how the designer names the entities based on the database name. This is a somewhat obscure feature in LightSpeed so here is what you need to do:
Here is an example which Ive used to check this:
The key bit in the strategy is turning off UseClrNamingConventions which will prevent LightSpeed from re-casing the entity name. You can adjust the other aspects as required. After this is all in place you should see the change when performing an Update Database where the generated entity name should now be based on your custom code.
|
|
|
That's fixed it. Thanks! It also seems to work just fine with a relative path in the Design Time Assembly entry (although I've not tested any of the lsmodel command line tools). And in case anyone else wonders in future, the element mentioned in the penultimate step is the "Model" element. Thanks, Chris |
|