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 <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 : Sun Aug 17 2008 - 01:29:58 EDT