So the original problem we are trying to solve is the table naming
conflict that is possible if we do not account for schemas. If there
is no table naming conflict, there is no problem with the current
mechanism. If there is, it equally breaks all PK generation engines
that we provide. Or am I missing some other aspects of it?
It now occurred to me that the limitation above is deeper than the PK
generation mechanism. EntityResolver is not schema aware, so
"schema1.table1" and "schema2.table1" will result in a conflict even
before we hit the PK generation, and even if multiple DataMaps are
used in the same domain to map the conflicting tables. So looks like
we need to investigate (and fix) that first, before getting to the PK
discussion.
Andrus
On Aug 17, 2008, at 12:37 AM, Kevin Menard wrote:
I agree that such a flag would support backward compatibility. I'm
a bit
dubious about its value though. So, by default we ship "broken"
behavior
and expect the user to toggle a checkbox to do the correct thing?
The use
of schemas may have nothing to do with naming conflicts, as well.
Moreover,
PKs shouldn't be treated any differently than tables are, at least
with
regards to qualifications of naming.
The level at which I'm talking doesn't have any effect on sequence-
based PK
generators, as far as I can tell. It would mostly affect
AUTO_PK_SUPPORT,
let DB-specific generators handle the finer details of working with
sequences.
Having said that, I do value backwards compatibility, so I'm not
against
100% against it. It just feels a bit dirty. I'd rather we do
something
like check the version of the datamap and let that determine the
default
value of the checkbox. Of course, even that raises problems with
people
that have been tracking the milestones . . .
--
Kevin
On Sat, Aug 16, 2008 at 4:38 PM, Andrus Adamchik <[EMAIL PROTECTED]
>wrote:
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
