I’m working with TDM 18.104.22.168, modelling for a postgresql 9.2 database.
my entities have some (7 for precision) “standard” attributes that alway appear at top.
In order to ease my job in preparing new entities, I’ve followed the advice I’ve seen somewhere in this site of using gallery…
I’ve prepared 5 domains for the standard attributes (and not 7 because some attributes are duplicated, with different meaning); the domains have inside also check constraints defined
I’ve prepared a “base” entity with only the 7 duplicated attributes, that uses the domains for their definition
I’ve saved the base entity inside a gallery
So far so good…
Then when I have to generate a new entity, I pick up the base entity from gallery and drop it in my model. Fantastic! Problem is, that every time I drop an entity from gallery, the check constraints inside domains defined at point 1) get duplicated!!! So, after generating 5 entities, I find inside my domains (and by consequence inside my entities) 5 times the same constraint defined… My feeling is that when I drop the entity from gallery, the software check for existence of domains, and in case are missing generates them too (useful for cross-model use of gallery btw)… but only if they exists… probably the same check (generate only if non-existant) has been forgotten for check constraints inside domains (probably for defaults also, but this is something I don’t use)
I’ve tried workarounding adding the constraint directly inside attribute of base entity, but there I have another weird (and if possible even more showstopper) problem. As I always use “named” constraints, I’ve added the constraint at attribute level with name and capion: ckc<%ColumnName%>, and sql (for example) <%ColumnName%> >= 0. But while with a similar constraint inside domain I correctly see a generated SQL like “constraint “ckc_my_columname” check (my_columname >= 0)”, if I add the domain directly at attribute level the generated SQL is a disappointing “constraint “ckc<%ColumnName%>” check (my_columname >= 0)”… that means that application variables for constraint name are NOT resolved when constraint is applied directly inside attribute, but only for constraint SQL!!! I’ve tried to use different application variables (Name, FullName, etc) but with no luck… !!!