I second this because as i see the DB Modeler is like an abstraction
layer/tool of the database in terms of a model and i would love to skip
any direct contact with the database (as i don't really care about the
specific database backend itself as long as it adheres and fulfils
Cayenne requirements).
Maybe i can make my point a little bit more clear with an example:
Let's say we have a simple Customer Table (composed of a integer PK id,
and some varchar name column) and a Customer Entity (composed of the
string name attribute). With only that given i can't identify a single
customer as i obviously don't want to expose the concept of a primary
key to the entity/object mapping and for various reasons where a
Customer Number simply doesn't match the meaning of a PK. So what i
would have to do is to introduce another column/attribute CustomerNumber
to the table and the entity.
Now this CustomerNumber is used to identify a single customer entity but
it doesn't prohibit the use of duplicate Customer Numbers. That's the
point where i have to go to the a DB Administration tool and put a
unique constraint to the CostumerNumber column to ensure uniqueness of
the entries since i can't do that in the DB Modeler. If i later on
recreate the database schema the constraints are no longer contained so
i have to maintain them in another "place".
So i guess the main question remains whether or not a unique constraint
should be part of the database model...
Cheers,
Daniel
I agree that unique indices are important to the model, just like
validating that a varchar is no more than (say) 12 characters.
Personally I'd like to see all indices in the Cayenne model if only
because it means we have one place to store the entire db schema
definition, but I do understand why this should be kept separate to the
Cayenne runtime.
