Generated views with model first
Joined: 20-May-2011
Joined: 20-May-2011
Walaa wrote:
Are you doing catalog refresh? If so, did you apply the updated DDL?
So you mean, after doing changes to the model we should apply scripts and only then refresh from database? It wont override anything in the models? 
It seems quite wrong for me, as I would like one way changes for models and one way changes for views, not both ways..
Joined: 20-May-2011
Joined: 20-May-2011
Could you at least try the latest build please to avoid you running into things we already fixed?
Joined: 20-May-2011
Joined: 20-May-2011
Otis wrote:
I see it can happen that the enumerator fails due to altered elements, because one of the changes could raise an event. I've attached a new (debug) build which enumerates over a list, not another enumerator. Could you try this one for me, please?
Actually that one did not produced any error..
However, I see lots of remapping which breaks our models..
Like:
Entity 'Address' Entity re-mapped to table 'Default.addresses'. Entity migrated to target 'Default.addresses'. Type definition of the target 'Default.Addresses.Id' of field 'Id' changed. Type properties Max length, precision and scale of field 'Id' synced with the type properties of target 'Default.Addresses.Id'. The field 'IdAddress' is no longer part of the identifying fields. The field 'Id' is now part of the identifying fields.
For me would be best so that refresh would ignore my created models and refresh only selected objects and not deleting not selected items.. Is it possible?
Joined: 20-May-2011
Joined: 25-Oct-2005
Joined: 20-May-2011
Having another database for views of course solves the problem, but adds more complexity for developers to maintain it
Joined: 25-Oct-2005
cerberis wrote:
Having another database for views of course solves the problem, but adds more complexity for developers to maintain it
Why would you need another database? You could connect the Database-First project to any database that had the view you wanted in.
Joined: 20-May-2011
cerberis wrote:
Otis wrote:
I see it can happen that the enumerator fails due to altered elements, because one of the changes could raise an event. I've attached a new (debug) build which enumerates over a list, not another enumerator. Could you try this one for me, please?
Actually that one did not produced any error..
Like:
Entity 'Address' Entity re-mapped to table 'Default.addresses'. Entity migrated to target 'Default.addresses'. Type definition of the target 'Default.Addresses.Id' of field 'Id' changed. Type properties Max length, precision and scale of field 'Id' synced with the type properties of target 'Default.Addresses.Id'. The field 'IdAddress' is no longer part of the identifying fields. The field 'Id' is now part of the identifying fields.
For me would be best so that refresh would ignore my created models and refresh only selected objects and not deleting not selected items.. Is it possible?
If it would, there would be 2 sources of truth, which isn't what will work. The rule of thumb is: you work model first, the script produced is what you run on the DB from which you refresh (if ever, you don't need to refresh from the DB, only if you want to import elements from the DB which you didn't add in model first). If you don't run the script on the DB, the project is in fact out of sync, and the relational model data in the project doesn't reflect how your DB looks like and it can't make decisions based on what it will look like at runtime when the generated code (which assumes the DB looks like the relational model data in the project) is run on the DB.
To me it looks like you refreshed your project with a DB that is totally out of sync with the relational model data in the project.
Joined: 20-May-2011
As I mentioned: our physical database model is always different from the model.
We are using historical tables which keeps history together with current data. That means our identity in model and identity in database are different.
So my wish - to have models which are not touched during the refresh. Some kind of flag on the model should be quite easy to implement
However for now I see that I need 2 databases or implement the view in the code.
That's what I was asking
Thank you.
Joined: 25-Oct-2005
cerberis wrote:
Project name is based on database name.. So I cannot have 2 schemas in the same project with the same name. If you mean copy/paste from *.llblgenproj file, that's really not the way to go.
I mean have two instances of LLBL running. One containing your existing Model-First project, the other containing a Database-First project completely generated from whatever DB has the view. The catalogs of the two would be much the same. Just copy and paste objects from one LLBL instance to the other (or alternatively import to Database-First project into the Model-First and the pick the objects you want).
No need for 2 DBs.
Though I think you will still have a problem if you have already have a view and you want add another field to it. Apart from deleting and re-adding, you would be looking at editing the *.llblgenproj directly - it's no so bad
cerberis wrote:
As I mentioned: our physical database model is always different from the model.
That's a little odd. Model first suggests the target DB changes (otherwise, why alter the model to get a different DB?) and at runtime the target DB has to match the relational model data the model is mapped to.
We are using historical tables which keeps history together with current data. That means our identity in model and identity in database are different. So my wish - to have models which are not touched during the refresh. Some kind of flag on the model should be quite easy to implement
It's not the technical aspect of it that's bothering me, no worries there 
The thing is: if the target schema the project is refreshed with isn't equal to the relational model and that's deliberately so and the relational model data in the project should NOT be migrated to that schema, why is it different as the model mapped to the relational model data then won't work at runtime as the database is different?
btw: you can have multiple catalogs (databases) in 1 project. You can decide to work model first on DB A (which is kept in sync in the target DB so refresh shows no changes) and have a view and several tables in DB B. You simply don't select the tables, just the view, and it will refresh properly. You map the model to DB A and an entity to the view in DB B. You can then decide at runtime to have everything in 1 DB (e.g. you moved the view to DB A) by overwriting the catalog name at runtime from B to A. Does that help?
Joined: 20-May-2011
That's actually the whole beauty of LLBLGenPro and why I like it: its very customizable and flexible .
Our model contains all the fields which are in database. However, field definitions are different.
For example, we have field 'Id' in each table, which is not PK in model, but it is IDENTITY in database (create/update script is generated using this convention).
We also have EntityId column, which is defined as PK in the model, but its a regular field in the database.
We have logical relations on EntityId column, which cannot be mapped to physical database relations. To be honest, we should use EntityId, ExistenceStart, ExistenceEnd as PK, but this makes a lot of troubles when creating foreign keys in database, as we need to have 3 columns for foreign key.
So we solve this by adding filters automatically at adapter level when creating select/update/delete queries.
Everything works fine and very good and we still can use all ORM features.
The only thing - we cannot refresh model from database because PK in model and PK in database are different
So for summary - probably we will use multiple catalogs even if it makes some more work for developers changing the views (or we will move views to the code).
cerberis wrote:
That's actually the whole beauty of LLBLGenPro and why I like it: its very customizable and flexible
Our model contains all the fields which are in database. However, field definitions are different. For example, we have field 'Id' in each table, which is not PK in model, but it is IDENTITY in database (create/update script is generated using this convention). We also have EntityId column, which is defined as PK in the model, but its a regular field in the database. We have logical relations on EntityId column, which cannot be mapped to physical database relations. To be honest, we should use EntityId, ExistenceStart, ExistenceEnd as PK, but this makes a lot of troubles when creating foreign keys in database, as we need to have 3 columns for foreign key.
Ok. You could set a setting where PKs don't follow PK constraints in the DB when refreshing btw, so they're seen as 'model only' (like relationships are too). Dont know whether you already use this.
So we solve this by adding filters automatically at adapter level when creating select/update/delete queries. Everything works fine and very good and we still can use all ORM features. The only thing - we cannot refresh model from database because PK in model and PK in database are different
Please set 'Identifying fields follow dbprimary key constraints' setting under catalog refresher to 'false' (it's 'default' by default, which means it uses the setting value of the preferences, which is likely set to 'true'). This will make the refresher leave the pk definitions in the model alone.
So for summary - probably we will use multiple catalogs even if it makes some more work for developers changing the views (or we will move views to the code).
If the setting I mentioned above isn't working out, that's indeed the best way (multiple catalogs)
Joined: 20-May-2011
Seems like the setting helped
Also I had to disable Sync mapped element names after refresh as it caused lowercase'ing model names.
Thank you.
So we can close the issue?
Joined: 20-May-2011