Andreas Voss wrote: > > 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. >
It is designed around these assumptions: The primary key in the database is always an automatically generated id column (long sequence number), aka surrogate key. Foreign keys always always match this id column. Another thing is the natural key (aka business key). Eg. socialSecurityNumber. This is used for equals and hashCode in the objects. It is not the primary key in the database, but it has a unique constraint in the database. The natural key can composed of: - one single attribute - several attributes - one or several objects in a referred BasicType object Andreas Voss wrote: > > 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. > The reason for not having a separate DB model is as you mention simplicity. Sculptor doesn't aim at supporting any type of mapping and design. It is based on some assumptions, limitations, design best practices, or whatever you prefer to call it. I think this is a good thing. General purpose is not always a good thing. Ok, how to solve your specific problem? Can you add surrogate keys (id columns) in your database schema? It is probably possible to create new code generation templates for Hibernate and DDL which can support natural keys as database primary/foreign keys, but probably with limitations. /Patrik -- View this message in context: http://www.nabble.com/-Sculptor--column-names-for-existing-database--tp15177242s17564p15474874.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
