Expanding on this some more...
So we may have a DataMap (or DataDomain) flag saying "Use target table
schema when accessing PK generation helper objects". By default this
will be false (current behavior), resulting in default schema for PK
generation objects. If a user expects naming conflicts (i.e. there is
a "schema1.table1" and "schema2.table1" in the same mapping), they can
change that to "true", and then we'd use "schema1.auto_pk_support" for
tables in schema1 and "schema2.auto_pk_support" for tables in schema2.
This ports nicely into sequence based PK generators (i.e. each pk
sequence will be created in the target schema, preventing any
possibility of conflicts). Another benefit is that it is backwards
compatible.
Andrus
On Aug 16, 2008, at 11:20 PM, Andrus Adamchik wrote:
I have doubts about this approach, aside from the fact that we will
force an upgrade step on everyone using schemas. How is this going
to work with sequence-based pk generators?
Maybe the PK generation supporting objects themselves should be
prefixed with schema names (as an option I guess) instead of storing
the schema in the lookup table?
Thoughts?
Andrus
On Aug 16, 2008, at 10:58 PM, Kevin Menard wrote:
In order to fix CAY-539 and CAY-730, I'm changing the default
JdbcPkGenerator use fullyQualifiedNames. For anyone not using a
schema,
this shouldn't be a problem. For those using schemas, but relying on
Cayenne to ignore them, they're going to have to delete the schema
in order
for things to work.
In theory this all should be fine . . . getFullyQualifiedName()
falls back
to getName() if appropriate. However, this is used by a fair
number of the
DbAdapters and I want to make sure that I haven't broken anything.
Thus,
testing on as many DBs as possible would be nice. I'd appreciate
any help
in this regard, whether it come from Hudson or other team members.
Otherwise, I'll be a bit reluctant to make the change, just because
I don't
want to break anything on anyone. I'll obviously test on whatever
platforms
I can.
--
Kevin
