You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Kevin Menard <ni...@gmail.com> on 2008/08/16 21:58:50 UTC
Possible breakage
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
Re: Possible breakage
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <andrus@objectstyle.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
>>>>
>>>
>>>
>>>
>>
Re: Possible breakage
Posted by Kevin Menard <ni...@gmail.com>.
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 <an...@objectstyle.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
>>>
>>
>>
>>
>
Re: Possible breakage
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
>
>
Re: Possible breakage
Posted by Kevin Menard <ni...@gmail.com>.
Well, the upgrade step is a byproduct of this being a bug to begin with. We
shouldn't be ignoring schemas if they're specified . . . If people are
relying on that behavior though, there's not much we can do with regards to
fixing the bug.
--
Kevin
On Sat, Aug 16, 2008 at 4:20 PM, Andrus Adamchik <an...@objectstyle.org>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
>>
>
>
Re: Possible breakage
Posted by Andrus Adamchik <an...@objectstyle.org>.
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