Community
Participate
Working Groups
In a RDBMS it is possible to add constraints to a table. In particular, meta model elements marked 'ID' should be handled as follows: Add a UNIQUE CONSTRAINT to the column of the appropriate table. DDL: alter table MYTYPE add constraint mytypeuniqueconstraint check (myattribute is unique);
(In reply to comment #0) > In a RDBMS it is possible to add constraints to a table. > In particular, meta model elements marked 'ID' should be handled as follows: > Add a UNIQUE CONSTRAINT to the column of the appropriate table. Why do youthink we *should* do that? Just because it's possible? I guess with auditing and branching that wouldn't that trivial...
Of course, there is no obligation to do this at all, maybe, it was just wrong wording... I did not consider auditing and branching as I have turned those features off (both are supported natively by the db storage).
Note to the note in parenthesis in my last comment: auditing is supported, I have confused branching with replication...
(In reply to comment #2) > Of course, there is no obligation to do this at all, maybe, it was just wrong > wording... Still I would like to learn about the benefit before we are going to change something. The fact that it's possible alone is not enough to justify effort and potential to break something.
Isn't the ID flag in ecore meant to avoid duplicate objects in a resource? If I want to avoid duplicate objects in CDO, I have to traverse the list and check whether that object already exists or not. The db store supports this natively, so why not use it?
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
