V3 Discussion: Model First and Entities with no database backend
Walter wrote:
Hello,
I understand that the Llblgen pro V3 will allow a "model first" approach. For what I understand you will keep the "reverse engineering" approach that consists of generating the entity model from the database + add the ability to first design the entity model and then connect to the database schema.
I have a few questions regarding this:
- Do you allow the database to be generated from the model ?
Yes
and if yes, do you have some kind of configuration data to control how the database will be generated? (exemple: for hierarchical data, you have several options for the target database schema).
The DB schema follows from the entity model. For inheritance, you specify per entity how the hierarchy type is, e.g. target per entity, or target per entity hierarchy. The verifier/schema modifier then updates the meta-data accordingly, e.g. adds FK constraints. The DDL SQL is then generated from that meta-data which simply follows what's in the meta-data.
Generation is done through .lpt templates which you can modify of course. We offer both Create scripts for all databases except ms access and also Update scripts for all databases except ms access (MS access will probably get a solution for this, though it's at the moment 'not supported' in this scenario). Update scripts simply contain DDL SQL statements to migrate an existing schema to the state of the meta-data. So if you added a 1:1 relationship based on an FK field, you'll get for example an Update script which adds the FK field, the FK constraint and the UC constraint on the fk field 
- Do you allow an entity model, designed apart from database, to be connected to an existing database through mapping configuration?
Yes. You can create a project, add meta-data later on, and then define entities by hand, and map them manually onto the tables in the metadata, or create new tables from the entities etc. There has to be meta-data defined in the project to map an entity on, as that's logical, otherwise there's no mapping. This meta-data can be added after you've created entities.
and if yes: supported for all ORM frameworks (llblgen, nhibernate, EF)? any limitation as compared to generation of database?
All frameworks are supported with the same features, though some frameworks don't support all designer features (e.g. TPE inheritance in L2S projects), and some edge case features are currently not supported by the designer which are supported by EF and NH, like mapping an entity onto multiple tables (without inheritance) and mapping an entity onto a stored proc resultset. We do support mapping a typedview onto a stored proc resultset in v3.0. We are looking into supporting the other features in a version after 3.0, (e.g. 3.1)
- Do you allow an entity model to be used as is, with no connection to any database? I explain myself: for some cases, it can be usefull to design part of the model that will be persisted to xml, rather than to database, or even with no need to be persisted and therefore used in memory only? The objective is to use this chunk of the model consistently (implementing same interfaces, having same helpers, field indexes etc.) with the rest of the model that is persisted to a database. I guess it is the case, for V2.6 it is possible too, however a bit cumbersome: you need to create a dummy database schema in order to generate an entity model from there... However: do you see it as a valid option? In other words: is it advisable to use the Llblgen designer to model a full entity business model for your application for both persited and not persisted data?
At the moment, the meta-data is seen as catalog/schema/table/view elements, and entities are mapped onto that. Every entity has to have a mapping, though what you do with the target is up to you. E.g. if you indeed decide to throw away a schema for XML mapping or not create it at all, that's up to you.
Perhaps in the future we'll add other meta-data sources, though as long as an XML storage looks like a catalog/schema/table/view, it doesn't matter and it's mappeable.
We do plan to support EUSS created by Sebastian Ros of Evaluant, perhaps you're familiar with it, and EUSS is capable of persisting to XML, so in the future we'll add support for it, at least it's likely, though in v3.0 you've to use the dummy schema trick.
Otis wrote:
Generation is done through .lpt templates which you can modify of course. We offer both Create scripts for all databases except ms access and also Update scripts for all databases except ms access
Great stuff!! Never thought of how the database could be generated (because did not need it). And indeed makes sense to use scripts and the existing lpt templates and code generation engine to do. + makes it very easy to specialize for specific needs how the database should be generated (for instance: maybe generate extra column on all entities if audit + last modified date required?)
However I guess the Create + Update scripts way of doing should be limited to the development database server. And use more robust and safe and verifyable way to update production database server. In fact keep the existing process, specific to your project, whatever it may be, to update production database server based on changes in development.
Otis wrote:
- Do you allow an entity model, designed apart from database, to be connected to an existing database through mapping configuration?
Yes. You can create a project, add meta-data later on, and then define entities by hand, and map them manually onto the tables in the metadata, or create new tables from the entities etc. There has to be meta-data defined in the project to map an entity on, as that's logical, otherwise there's no mapping. This meta-data can be added after you've created entities.
At the moment, the meta-data is seen as catalog/schema/table/view elements, and entities are mapped onto that. Every entity has to have a mapping, though what you do with the target is up to you. E.g. if you indeed decide to throw away a schema for XML mapping or not create it at all, that's up to you.
Don't really get why there must be a mapping for every entity, even though I can see where you're coming from. I mean: you can define an entity first and add the binding later one. It means that you have the ability to model an entity with no mapping. I understand you need the mapping to generate the database specific layer, however could not an entity defined with no mapping be generated in the database independant layer with no equivalent generated code in the database specific layer? That would allow an entity to be usable to store data in memory, with no persistance (or manually through serialization to XML).
Otis wrote:
Perhaps in the future we'll add other meta-data sources
Yes that would IMHO be great as it would allow the generated business layer to be a generic way to represent all data that has to be part of the project, with no concern of where this data could come from (web services, file, database, memory, ESB,. ..), and therefore standardize the way to access data
Otis wrote:
We do plan to support EUSS created by Sebastian Ros of Evaluant, perhaps you're familiar with it, and EUSS is capable of persisting to XML, so in the future we'll add support for it, at least it's likely, though in v3.0 you've to use the dummy schema trick.
I don't know EUSS, but will have a look, I can see it is a french company as I am, so would be easy for me to go and see them
Kind Regards Walter Almeida
Walter wrote:
Otis wrote:
Generation is done through .lpt templates which you can modify of course. We offer both Create scripts for all databases except ms access and also Update scripts for all databases except ms access
Great stuff!! Never thought of how the database could be generated (because did not need it). And indeed makes sense to use scripts and the existing lpt templates and code generation engine to do. + makes it very easy to specialize for specific needs how the database should be generated (for instance: maybe generate extra column on all entities if audit + last modified date required?)
If you don't want the audit fields to be settable in code, you could do it in the DDL templates of course. We'll also support multiple entities on the same table which have a 1:1 relationship over the PK in v3, so you can have two entities on the same row in the db: one being the audit part and one being the normal record for example.
However I guess the Create + Update scripts way of doing should be limited to the development database server. And use more robust and safe and verifyable way to update production database server. In fact keep the existing process, specific to your project, whatever it may be, to update production database server based on changes in development.
Migrating a production system is always a complex operation: special migration scripts have to be written, it has to be tested first, then it has to be ran, verified etc.. We didnt invest time in this, as most DBA's will do it themselves and won't let a tool do this for them. That's also why we generate DDL SQL scripts, so the DBA can use them to build the migration system using them. It's readable code
Otis wrote:
- Do you allow an entity model, designed apart from database, to be connected to an existing database through mapping configuration?
Yes. You can create a project, add meta-data later on, and then define entities by hand, and map them manually onto the tables in the metadata, or create new tables from the entities etc. There has to be meta-data defined in the project to map an entity on, as that's logical, otherwise there's no mapping. This meta-data can be added after you've created entities.
At the moment, the meta-data is seen as catalog/schema/table/view elements, and entities are mapped onto that. Every entity has to have a mapping, though what you do with the target is up to you. E.g. if you indeed decide to throw away a schema for XML mapping or not create it at all, that's up to you.
Don't really get why there must be a mapping for every entity, even though I can see where you're coming from. I mean: you can define an entity first and add the binding later one. It means that you have the ability to model an entity with no mapping. I understand you need the mapping to generate the database specific layer, however could not an entity defined with no mapping be generated in the database independant layer with no equivalent generated code in the database specific layer? That would allow an entity to be usable to store data in memory, with no persistance (or manually through serialization to XML).
true, though for v3.0 we opted for a 1:1 projection to code. It's also easier to add properties manually in code which aren't persisted for example. In the future we might introduce a more customizable projection to code from the abstact entity definition. The projection to database tables is already more configurable, e.g. you can opt how to define inheritance.
V3 is a massive step forwards, especially in how users manage their entity definitions and the mappings both to code and database. The runtime will get enhancements for the new features we introduced in the designer, though the amount of changes are mostly in the designer.
Otis wrote:
If you don't want the audit fields to be settable in code, you could do it in the DDL templates of course. We'll also support multiple entities on the same table which have a 1:1 relationship over the PK in v3, so you can have two entities on the same row in the db: one being the audit part and one being the normal record for example.
Multiple entities on same table?? Hey that's great I wonder how far it goes:
Would it possible to have an entity called let's see AuditInfo, mapped to several tables in the database schema, while all these tables mapped to their own entities? so you have a customer entity mapped to a a customer table and an auditinfo entity mapped to part of the customer table and then a company entity mapped to a company table and the same auditinfo entity mapped to part of the company table etc. ? That would help manage kind of transversal "aspects" of your model, in an object oriented way in code, and efficiently on database through database columns?
Otis wrote:
Migrating a production system is always a complex operation: special migration scripts have to be written, it has to be tested first, then it has to be ran, verified etc.. We didnt invest time in this, as most DBA's will do it themselves and won't let a tool do this for them. That's also why we generate DDL SQL scripts, so the DBA can use them to build the migration system using them. It's readable code
Ok 100% agree
Otis wrote:
V3 is a massive step forwards, especially in how users manage their entity definitions and the mappings both to code and database. The runtime will get enhancements for the new features we introduced in the designer, though the amount of changes are mostly in the designer.
Yes, really looking forward to try the new version )
Walter wrote:
Otis wrote:
If you don't want the audit fields to be settable in code, you could do it in the DDL templates of course. We'll also support multiple entities on the same table which have a 1:1 relationship over the PK in v3, so you can have two entities on the same row in the db: one being the audit part and one being the normal record for example.
Multiple entities on same table?? Hey that's great
No, that's not going to work, an entity has 1 target.
Though, you can use value types. They can contain 1 or more fields and are a type you can use for a single field. So you for example define 4 audit fields in an Audit value type and add to an entity which is audited an extra field: AuditInfo, of type Audit. Then you can map the 4 field in Audit to the target fields in the same table/view as the entity has.