The models I have use composite keys. As you describe in the advanced tutorial, these are supported by Sculptor - but I do not really understand the last sentence "All persistent Entities and Value Objects will also have a surrogate id attribute, which is the primary key in the database". In our database there is no single primary key column.
After thinking about this issue a little more, it seems that a single column name for a reference will not work with composite keys. It should be possible to enumerate all foreign key columns that match the primary key columns of the referenced entity. Not sure, if the DSL can be expanded in an easy way to support this. Additional complexity could come from m:n relations as you mentioned with composite keys. So I'm not sure, if its a good idea to "pollute" the DDD DSL with all this stuff. Maybe there should be a separate database mapping model similar to the separate gui model. I like the way EMF separates these things, they have the core *.ecore model, the GUI model (*.genmodel), the diagram model *.ecore_diagram etc. Maybe the db mapping is worth its own model - but maybe its simpler (and more convenient) to have things together. Just thinking. Patrik Nordwall wrote: > > The basic idea is to add the following to the metamodel (and also in DSL): > - dbtable in DomainObject > - dbcolumn in Attribute > - dbcolumn in Reference > -- View this message in context: http://www.nabble.com/-Sculptor--column-names-for-existing-database--tp15177242s17564p15469065.html Sent from the Fornax-Platform mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fornax-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fornax-developer
