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 . . .
-- KevinOn Sat, Aug 16, 2008 at 4:38 PM, Andrus Adamchik <andru..bjectstyle.org>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 >>> >> >> >> >
This archive was generated by hypermail 2.0.0 : Sat Aug 16 2008 - 17:38:27 EDT