That was it! We had a to-many relationship where the key wasn't a
primary key in the source table. I'm not sure why... the database
design is years old. I switched to using the source pk
(add a column to the destination table, populate it, remove the old
column) and the problem went away. Thanks! Hope this is helpful to others.
Andrus Adamchik wrote:
> Bryan,
>
> I pointed out to the known things first ;-)
>
> Another thing that I noticed for CAY-231 (IIRC, need some time to look at
> it for real) was that to-many relationship wasn't based on a source PK
> (instead it uses a regular column). This limitation was fixed for 1..1
> relationships, but looks like it breaks for 1..n. Could you doublecheck
> that? If this is indeed the problem, I guess we need to reopen CAY-231.
>
> Andrus
>
>
>
>
>>Hmm, well... it's true that my example didn't have a reverse
>>relationship for the to-many at the object level. But when I
>>added one just now, it didn't change the problem.
>>
>>
>>Andrus Adamchik wrote:
>>
>>>Michal,
>>>
>>>I looked at CAY-231 submitted by Bryan, and I suspect that his problem
>>>happens cause to-many object relationship doesn't have a reverse
>>>to-one (this is currently a requirement in Cayenne -
>>>http://objectstyle.org/cayenne/modelerguide/modeling-tips.html). Is it
>>>possible that you have the same situation?
>>>
>>>Our archiver messed u the XML files you uploaded with the earlier
>>>message, so I can't doublecheck this from here.
>>>
>>>Andrus
>>>
>>>
>>>
>>>
>>>>Okay here is another quirk that is definetly related, the original
>>>>problem I posted created as you know the query
>>>>
>>>>SELECT t0.Disabled, t0.FirstName, t0.LastName, t0.LoginName,
>>>>t0.UserId, t0.UnitId FROM dbo._UserInfo t0 WHERE t0.UnitId = NULL
>>>>
>>>>and this was going from
>>>>Discipline.externalId -> _UserInfo.UnitId
>>>>
>>>>now there is another relation that links user's to discipline and that
>>>>is a double join table, which I don't flatten.
>>>>
>>>>Discipline.id ->
>>>> ProjectDisciplin.disciplineId
>>>> ProjectDisicpline.id ->
>>>> ProjectDisciplineUser.projectDisciplineId
>>>> ProjectDisciplineUser.userId ->
>>>> _UserInfo.UserId
>>>>
>>>>now here's the kicker, when I create a new ProjectDisciplineUser
>>>>relationship, it creates but the problem is that it tries to updata
>>>>the _UserInfo.UnitId to NULL. Now this is a locked object as it is on
>>>>a seperate live database, so it give me an exception. But the error
>>>>is cause by an UPDATE query that is updating the UserId(to whatever
>>>>userId i'm setting) and the UnitId(to NULL).
>>>>
>>>>Now when I remove the link in the cayenne files between
>>>>Discipline.externalId -> _UserInfo.UnitId
>>>>everything works great. This is the link that created my original
>>>>problem/posting. I have a very strong feeling these a related but I
>>>>really don't know why the field would be set to NULL.
>>>>
>>>>Thanks for all this help.
>>>>
>>>>Cheers
>>>>Mike
>>>>
>>>>-----Original Message-----
>>>>From: Andrus Adamchik [mailto:andru..bjectstyle.org]
>>>>Sent: Tuesday, November 09, 2004 7:04 PM
>>>>To: cayenne-use..bjectstyle.org
>>>>Subject: Re: Getting info across databases...
>>>>
>>>>
>>>>Let me take a look at the bug report. That indeed looks strange.
>>>>Thanks for the test case!
>>>>
>>>>Andrus
>>>>
>>>>On Nov 9, 2004, at 12:22 PM, Bryan Lewis wrote:
>>>>
>>>>
>>>>
>>>>>I think I can help on reproducing the problem. We ran into the same
>>>>>issue today with a SQL statement ending in "= NULL", for no good
>>>>>reason that we can see. It's a simple one-to-many relationship using
>>>>>a VARCHAR field as the key.
>>>>>
>>>>>I had a good test case from a previous bug report that seemed to work
>>>>>well for Andrus. I've updated it to cover this case and submitted it
>>>>>as CAY-231.
>>>>>
>>>>>
>>>>>Michal Kozlowski wrote:
>>>>>
>>>>>
>>>>>
>>>>>>I feel I'm doing something wrong b/c you couldn't reproduce the
>>>>>>problem.
>>>
This archive was generated by hypermail 2.0.0 : Thu Nov 18 2004 - 20:56:21 EST