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 - 16:39:36 EST