You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Jakob Braeuchi <jb...@gmx.ch> on 2003/03/01 23:26:29 UTC
Re: OJB test failures
hi andrew,
i changed Identity to do a convertToSql when called with an object, no
conversion takes place when called with pkValues.
with this change all conversion test are passed. i have a version where
conversion takes place during binding of the variables, but this version
fails on the referrer test :(
should we drop conversion of pk values completely ?
jakob
Andrew Gilbert wrote:
>Armin,
>
>Thank you very much for this! I will build latest and re-test soon.
>
>The bummer is, it would be a major impediment to our use of OJB if we couldn't convert on pk fields. We use a custom GUID impl for the pk in many of our BO's and tables.
>
>Not sure I fully understand yet the Identity change. Sounds like you are saying internal state was inconsistent?
>
>
>
>>######
>>I think the made changes are correct, because the conversion
>>was not transparent for the user of the Identity object. I suggest
>>never use converted (java --> sql) pk fields within Identity
>>(I don't know if code base is comply with this suggest,
>>maybe that's the reason for the hassle).
>>The conversion could be done when it's necessary.
>>But nevertheless I think there is a nasty bug when using
>>field conversion with pk fields.
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
Re: OJB test failures
Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi Jakob,
great work!!
regards,
Armin
----- Original Message -----
From: "Jakob Braeuchi" <jb...@gmx.ch>
To: "OJB Users List" <oj...@db.apache.org>
Sent: Sunday, March 02, 2003 11:00 AM
Subject: Re: OJB test failures
> hi thomas,
>
> field conversion should be ok now. all conversion testcases pass.
> i also fixed a minor glitch in collection proxy clear() which makes
> MtoNMmapping pass as well.
>
> jakob
>
> Thomas Mahler wrote:
>
> > Hi all,
> >
> > Jakob Braeuchi wrote:
> >
> >> hi andrew,
> >>
> >> i changed Identity to do a convertToSql when called with an object,
> >> no conversion takes place when called with pkValues.
> >> with this change all conversion test are passed. i have a version
> >> where conversion takes place during binding of the variables, but
> >> this version fails on the referrer test :(
> >>
> >> should we drop conversion of pk values completely ?
> >
> >
> > There are several users that use some kind of GUID objects as
primary
> > key attributes. Those GUID need FieldConversions to be mapped to a
> > (e.g.) VARCHAR column.
> > So dropping this feature is not an option.
> >
> > We have to make sure that FieldConversions are properly applied for
pk
> > fields too.
> >
> > cheers,
> > Thomas
> >
> >>
> >> jakob
> >>
> >> Andrew Gilbert wrote:
> >>
> >>> Armin,
> >>>
> >>> Thank you very much for this! I will build latest and re-test
soon.
> >>> The bummer is, it would be a major impediment to our use of OJB if
> >>> we couldn't convert on pk fields. We use a custom GUID impl for
the
> >>> pk in many of our BO's and tables.
> >>>
> >>> Not sure I fully understand yet the Identity change. Sounds like
you
> >>> are saying internal state was inconsistent?
> >>>
> >>>
> >>>
> >>>> ######
> >>>> I think the made changes are correct, because the conversion
> >>>> was not transparent for the user of the Identity object. I
suggest
> >>>> never use converted (java --> sql) pk fields within Identity
> >>>> (I don't know if code base is comply with this suggest,
> >>>> maybe that's the reason for the hassle).
> >>>> The conversion could be done when it's necessary.
> >>>> But nevertheless I think there is a nasty bug when using
> >>>> field conversion with pk fields.
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
>
>>> --------------------------------------------------------------------
-
> >>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> >>> For additional commands, e-mail: ojb-user-help@db.apache.org
> >>>
> >>>
> >>>
> >>>
> >>
> >>
>
>> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> >> For additional commands, e-mail: ojb-user-help@db.apache.org
> >>
> >>
> >
> >
> >
>
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
Re: OJB test failures
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi thomas,
field conversion should be ok now. all conversion testcases pass.
i also fixed a minor glitch in collection proxy clear() which makes
MtoNMmapping pass as well.
jakob
Thomas Mahler wrote:
> Hi all,
>
> Jakob Braeuchi wrote:
>
>> hi andrew,
>>
>> i changed Identity to do a convertToSql when called with an object,
>> no conversion takes place when called with pkValues.
>> with this change all conversion test are passed. i have a version
>> where conversion takes place during binding of the variables, but
>> this version fails on the referrer test :(
>>
>> should we drop conversion of pk values completely ?
>
>
> There are several users that use some kind of GUID objects as primary
> key attributes. Those GUID need FieldConversions to be mapped to a
> (e.g.) VARCHAR column.
> So dropping this feature is not an option.
>
> We have to make sure that FieldConversions are properly applied for pk
> fields too.
>
> cheers,
> Thomas
>
>>
>> jakob
>>
>> Andrew Gilbert wrote:
>>
>>> Armin,
>>>
>>> Thank you very much for this! I will build latest and re-test soon.
>>> The bummer is, it would be a major impediment to our use of OJB if
>>> we couldn't convert on pk fields. We use a custom GUID impl for the
>>> pk in many of our BO's and tables.
>>>
>>> Not sure I fully understand yet the Identity change. Sounds like you
>>> are saying internal state was inconsistent?
>>>
>>>
>>>
>>>> ######
>>>> I think the made changes are correct, because the conversion
>>>> was not transparent for the user of the Identity object. I suggest
>>>> never use converted (java --> sql) pk fields within Identity
>>>> (I don't know if code base is comply with this suggest,
>>>> maybe that's the reason for the hassle).
>>>> The conversion could be done when it's necessary.
>>>> But nevertheless I think there is a nasty bug when using
>>>> field conversion with pk fields.
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: OJB test failures
Posted by Thomas Mahler <th...@web.de>.
Hi all,
Jakob Braeuchi wrote:
> hi andrew,
>
> i changed Identity to do a convertToSql when called with an object, no
> conversion takes place when called with pkValues.
> with this change all conversion test are passed. i have a version where
> conversion takes place during binding of the variables, but this version
> fails on the referrer test :(
>
> should we drop conversion of pk values completely ?
There are several users that use some kind of GUID objects as primary
key attributes. Those GUID need FieldConversions to be mapped to a
(e.g.) VARCHAR column.
So dropping this feature is not an option.
We have to make sure that FieldConversions are properly applied for pk
fields too.
cheers,
Thomas
>
> jakob
>
> Andrew Gilbert wrote:
>
>> Armin,
>>
>> Thank you very much for this! I will build latest and re-test soon.
>> The bummer is, it would be a major impediment to our use of OJB if we
>> couldn't convert on pk fields. We use a custom GUID impl for the pk in
>> many of our BO's and tables.
>>
>> Not sure I fully understand yet the Identity change. Sounds like you
>> are saying internal state was inconsistent?
>>
>>
>>
>>> ######
>>> I think the made changes are correct, because the conversion
>>> was not transparent for the user of the Identity object. I suggest
>>> never use converted (java --> sql) pk fields within Identity
>>> (I don't know if code base is comply with this suggest,
>>> maybe that's the reason for the hassle).
>>> The conversion could be done when it's necessary.
>>> But nevertheless I think there is a nasty bug when using
>>> field conversion with pk fields.
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: OJB test failures
Posted by Thomas Mahler <th...@web.de>.
Hi again Jakob,
Jakob Braeuchi wrote:
> hi all,
>
> after a sleep and further digging in the code i found that the source of
> the problem is the convertToSql
> ObjectReferenceDescriptor#getForeignKeyValues. conversion TO sql should
> be done ONLY when binding an sql-statement, that's what i've changed now.
> so the identity-object will always carry the java format of key-values.
this seems to be the most clean solution to me.
>
> and of course we do NOT drop conversion of pk values. may be it was too
> late ;-)
:-)
liebe Gruesee,
Thomas
>
> hth
> jakob
>
> Jakob Braeuchi wrote:
>
>> hi andrew,
>>
>> i changed Identity to do a convertToSql when called with an object, no
>> conversion takes place when called with pkValues.
>> with this change all conversion test are passed. i have a version
>> where conversion takes place during binding of the variables, but this
>> version fails on the referrer test :(
>>
>> should we drop conversion of pk values completely ?
>>
>> jakob
>>
>> Andrew Gilbert wrote:
>>
>>> Armin,
>>>
>>> Thank you very much for this! I will build latest and re-test soon.
>>> The bummer is, it would be a major impediment to our use of OJB if we
>>> couldn't convert on pk fields. We use a custom GUID impl for the pk
>>> in many of our BO's and tables.
>>>
>>> Not sure I fully understand yet the Identity change. Sounds like you
>>> are saying internal state was inconsistent?
>>>
>>>
>>>
>>>> ######
>>>> I think the made changes are correct, because the conversion
>>>> was not transparent for the user of the Identity object. I suggest
>>>> never use converted (java --> sql) pk fields within Identity
>>>> (I don't know if code base is comply with this suggest,
>>>> maybe that's the reason for the hassle).
>>>> The conversion could be done when it's necessary.
>>>> But nevertheless I think there is a nasty bug when using
>>>> field conversion with pk fields.
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: OJB test failures
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi all,
after a sleep and further digging in the code i found that the source of
the problem is the convertToSql
ObjectReferenceDescriptor#getForeignKeyValues.
conversion TO sql should be done ONLY when binding an sql-statement,
that's what i've changed now.
so the identity-object will always carry the java format of key-values.
and of course we do NOT drop conversion of pk values. may be it was too
late ;-)
hth
jakob
Jakob Braeuchi wrote:
> hi andrew,
>
> i changed Identity to do a convertToSql when called with an object, no
> conversion takes place when called with pkValues.
> with this change all conversion test are passed. i have a version
> where conversion takes place during binding of the variables, but this
> version fails on the referrer test :(
>
> should we drop conversion of pk values completely ?
>
> jakob
>
> Andrew Gilbert wrote:
>
>> Armin,
>>
>> Thank you very much for this! I will build latest and re-test soon.
>> The bummer is, it would be a major impediment to our use of OJB if we
>> couldn't convert on pk fields. We use a custom GUID impl for the pk
>> in many of our BO's and tables.
>>
>> Not sure I fully understand yet the Identity change. Sounds like you
>> are saying internal state was inconsistent?
>>
>>
>>
>>> ######
>>> I think the made changes are correct, because the conversion
>>> was not transparent for the user of the Identity object. I suggest
>>> never use converted (java --> sql) pk fields within Identity
>>> (I don't know if code base is comply with this suggest,
>>> maybe that's the reason for the hassle).
>>> The conversion could be done when it's necessary.
>>> But nevertheless I think there is a nasty bug when using
>>> field conversion with pk fields.
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
Re: m:n decomposed and non-decomposed relations
Posted by Thomas Mahler <th...@web.de>.
I see no problem here.
Thomas
Yuji Shinozaki wrote:
> Can you deal with a relation as a non-decomposed m:n in one object and as
> a decomposed m:n another? Will you run into problems doing this?
>
> For example, suppose you have a USER table and a ROLE table that are
> related by a USER_ROLE table: a simple m:n relationship which I would like
> to deal with as a non-decomposed m:n in the USER and ROLE objects, so that
> you can simply do user.getRoleCollection() or a role.getUserCollection().
>
> Also suppose there is also an ITEM and LIST table in an m:n relationship
> via a ITEM_LIST table. I would like to treated as non-decomposed one, so
> that you could have item.getListCollection(), list.getItemCollection()
> methods.
>
> There is also an INCLUSION table that relates the USER_ROLE and ITEM_LIST
> tables in an m:n relationship (To tell you who in what role, included what
> item in which list. And yes, multiple user/roles can include the same
> item in a list -- sort of a "list of people who requested this item on
> this list").
>
> In the object model, I would like treat that Inclusion relationship as
> decomposed. So that I could have a method list.getInclusionCollection()
> which would give me all the Inclusions to this list.
>
> USER_ROLE is both involved in an m:n decomposed and m:n non-decomposed
> relationship. Will this cause problems?
>
>
> USER: USER_ROLE: ROLE:
> USER_ID(PK) USER_ID(FK:USER) ROLE_ID(PK)
> ROLE_ID(FK:ROLE)
>
> ITEM: ITEM_LIST: LIST:
> ITEM_ID(PK) ITEM_ID(FK: ITEM) LIST_ID(PK)
> LIST_ID(FK: LIST)
>
> INCLUSION:
> USER_ID,ROLE_ID(FK: USER_ROLE)
> ITEM_ID,LIST_ID(FK: ITEM_LIST)
>
> Thanks in advanced,
>
> yuji
> ----
> Yuji Shinozaki Computer Systems Senior Engineer
> ys2n@virginia.edu Advanced Technologies Group
> (804)924-7171 Information Technology & Communication
> http://www.people.virginia.edu/~ys2n University of Virginia
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
m:n decomposed and non-decomposed relations
Posted by Yuji Shinozaki <ys...@virginia.edu>.
Can you deal with a relation as a non-decomposed m:n in one object and as
a decomposed m:n another? Will you run into problems doing this?
For example, suppose you have a USER table and a ROLE table that are
related by a USER_ROLE table: a simple m:n relationship which I would like
to deal with as a non-decomposed m:n in the USER and ROLE objects, so that
you can simply do user.getRoleCollection() or a role.getUserCollection().
Also suppose there is also an ITEM and LIST table in an m:n relationship
via a ITEM_LIST table. I would like to treated as non-decomposed one, so
that you could have item.getListCollection(), list.getItemCollection()
methods.
There is also an INCLUSION table that relates the USER_ROLE and ITEM_LIST
tables in an m:n relationship (To tell you who in what role, included what
item in which list. And yes, multiple user/roles can include the same
item in a list -- sort of a "list of people who requested this item on
this list").
In the object model, I would like treat that Inclusion relationship as
decomposed. So that I could have a method list.getInclusionCollection()
which would give me all the Inclusions to this list.
USER_ROLE is both involved in an m:n decomposed and m:n non-decomposed
relationship. Will this cause problems?
USER: USER_ROLE: ROLE:
USER_ID(PK) USER_ID(FK:USER) ROLE_ID(PK)
ROLE_ID(FK:ROLE)
ITEM: ITEM_LIST: LIST:
ITEM_ID(PK) ITEM_ID(FK: ITEM) LIST_ID(PK)
LIST_ID(FK: LIST)
INCLUSION:
USER_ID,ROLE_ID(FK: USER_ROLE)
ITEM_ID,LIST_ID(FK: ITEM_LIST)
Thanks in advanced,
yuji
----
Yuji Shinozaki Computer Systems Senior Engineer
ys2n@virginia.edu Advanced Technologies Group
(804)924-7171 Information Technology & Communication
http://www.people.virginia.edu/~ys2n University of Virginia