can't get rid of 'Changes pending', destroying the mappings

Posts   
 
    
wtijsma
User
Posts: 252
Joined: 18-Apr-2006
# Posted on: 22-Feb-2012 16:27:47   

Hi,

In LLBLGen Pro 2.6 I commonly used to use the multi DB feature for having a scenario like this: - a legacy DB (Oracle, DB2) - recreated the same database in SQL locally for ease of development - use the command line tool to (re)generate the LLBLGen project mapping to multiple databases. This worked fine.

Now as of 3.1, I have the same need, but LLBLGen just keeps messing with the field mappings, it always wants to generate update scripts (though I only work DB first).

Some more details: - The DB2 DB has no primary keys, and no foreign keys - In SQL, I add the foreign keys and primary keys - If I refresh from the SQL server version, I always keep 'changes pending' on the DB - When I generate the update scripts, it seems to want to rename all the DB2 columns that have primary key columns added in SQL server to different the property names of the entities (?)

In general, I've noticed that in many cases LLBLGen wants to generate update scripts for schema, even though I've never intended to change anything there, and it's really annoying, and in this case even unworkable.

What I would like is to be able to do is just disable all schema changes? This should make the entity updating logic easier too...

Any ideas?

Walaa avatar
Walaa
Support Team
Posts: 14946
Joined: 21-Aug-2005
# Posted on: 22-Feb-2012 18:14:51   

Could you pease describe how LLBLGen is missing with the fields mapping? And if possible attach a repor project file.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 23-Feb-2012 12:24:59   

If you do generate the ddl sql update script, what exactly is altered in the script? That might be a hint where to check. Also, make sure you're using the latest build.

Frans Bouma | Lead developer LLBLGen Pro
wtijsma
User
Posts: 252
Joined: 18-Apr-2006
# Posted on: 23-Feb-2012 13:09:25   

Otis wrote:

If you do generate the ddl sql update script, what exactly is altered in the script? That might be a hint where to check. Also, make sure you're using the latest build.

I've solved some of the issues by just setting all the "...Follows..." properties in the project to false.

There's still strange issues though, I refreshed the SQL database where I added constraints which added all navigators, however refreshing DB2 after that removed them again. After refreshing SQL again they're not added again, and it keeps 'pending changes' active wanting to remove the constraints.

One of the other problems is that you can't refresh if there's validation errors (which as caused annoyance in other scenarios as well), but for example if you have a nullable column in DB 1 that's not nullable in DB 2, it will cause a validation error. However you can never refresh your schema anymore without completely deleting the property from the entity (and all related navigators), because you can never adapt it to a valid scenario.

Seems like the only thing that really works is keeping both schema's exactly the same, and make all the customizations model-only in LLBLGen Pro.

I do think not being able to map 'loosely' to a DB is a shortcoming though, because sometimes you have badly designed legacy databases and you can't change field lengths, column types etc but in your entity model you do want to be able to create relations between them.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 23-Feb-2012 20:27:59   

wtijsma wrote:

Otis wrote:

If you do generate the ddl sql update script, what exactly is altered in the script? That might be a hint where to check. Also, make sure you're using the latest build.

I've solved some of the issues by just setting all the "...Follows..." properties in the project to false.

If there are model elements which aren't in the DB, you have to, this is logical.

There's still strange issues though, I refreshed the SQL database where I added constraints which added all navigators, however refreshing DB2 after that removed them again. After refreshing SQL again they're not added again, and it keeps 'pending changes' active wanting to remove the constraints.

If 1 db doesn't have constraints while the other one does, you indeed run into this, this is unsolvable. However, you can simply toss away the create script or press the button to ignore the changes on the dialog which pops up (bottom option).

One of the other problems is that you can't refresh if there's validation errors (which as caused annoyance in other scenarios as well), but for example if you have a nullable column in DB 1 that's not nullable in DB 2, it will cause a validation error. However you can never refresh your schema anymore without completely deleting the property from the entity (and all related navigators), because you can never adapt it to a valid scenario.

If you map a model to 2 databases, they both should end up the same. If one DB can't be altered, you get differences between model and DB. So updating the schema in the project fixes this, but this requires you exporting a script. However the dialog which tells you to do so can be used to ignore it. All changes will then be ignored.

This isn't solvable, as the model has to be in sync with the schema. Otherwise the model can't be migrated to the new db schema after a refresh, simply because an invalid model can be anything.

Seems like the only thing that really works is keeping both schema's exactly the same, and make all the customizations model-only in LLBLGen Pro.

I do think not being able to map 'loosely' to a DB is a shortcoming though, because sometimes you have badly designed legacy databases and you can't change field lengths, column types etc but in your entity model you do want to be able to create relations between them.

You can map 'loosely' but only up to a point, as the model itself has to be valid and at some point the mappings too. You have two DBs where one doesn't follow the model at some point so you get a discrepancy which isn't solvable automatically.

It's impossible to simply have a model and map it to a totally different schema, as one follows from the other.

Frans Bouma | Lead developer LLBLGen Pro
wtijsma
User
Posts: 252
Joined: 18-Apr-2006
# Posted on: 27-Feb-2012 13:53:19   

Otis wrote:

You can map 'loosely' but only up to a point, as the model itself has to be valid and at some point the mappings too. You have two DBs where one doesn't follow the model at some point so you get a discrepancy which isn't solvable automatically.

It's impossible to simply have a model and map it to a totally different schema, as one follows from the other.

It would be nice to have the possibility to refresh the database schema without adapting the entities, so I can just to the mapping myself?

In 2.6 it was always useful to be able to have model-only relations on nvarchars with different lengths. Same for mapping properties + columns with different lengths...

I can see that strictness is something you want by default, but sometimes you don't have the luxury to adapt the DB schema but you still want to have your mappings as good as possible

Walaa avatar
Walaa
Support Team
Posts: 14946
Joined: 21-Aug-2005
# Posted on: 27-Feb-2012 14:57:22   

sometimes you don't have the luxury to adapt the DB schema but you still want to have your mappings as good as possible

In such cases I always prefer to use a copy adapted schema, just for using with the designer. While the applications keeps targeting the original schema.

wtijsma
User
Posts: 252
Joined: 18-Apr-2006
# Posted on: 27-Feb-2012 15:07:32   

Walaa wrote:

sometimes you don't have the luxury to adapt the DB schema but you still want to have your mappings as good as possible

In such cases I always prefer to use a copy adapted schema, just for using with the designer. While the applications keeps targeting the original schema.

Well that's exactly what I'm trying, except I don't want to install DB2 on my system, so I created a local SQL Server database with modifications, then run the same project on a DB2 database without constraints in production.