And at the same time I confirmed that Michal's problem was the same
exact case - Dicipline.externalId wasn't a PK. So I simply faked a PK
column (marked externalId as PK without changing the underlying DB),
and it started to work..
Anyway, will need to support this better in the future, so I reopened
CAY-231.
Andrus
On Nov 18, 2004, at 8:55 PM, Bryan Lewis wrote:
> 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 - 21:05:35 EST