Re: To-one relationship not updated
Re: To-one relationship not updated
- Subject: Re: To-one relationship not updated
- From: Calven Eggert <email@hidden>
- Date: Tue, 14 Nov 2006 09:48:36 +0100
- Thread-topic: To-one relationship not updated
Title: Re: To-one relationship not updated
Thanks Robert. I didn’t know that. I’ve now changed all my timestamps to datetime.
I have also read that any long varchar fields should not be locked as well. Can you tell me exactly what is considered long? I’ve considered anything over 128 characters to be long.
Calven
Message: 1
Date: Mon, 13 Nov 2006 12:38:26 -0500
From: Robert Walker
Subject: Re: To-one relationship not updated
To: WebObjects Dev Apple <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset="us-ascii"
Calven,
Before going much further, please check the model for your MySQL
database to make sure your are using DATETIME for all your date/time
columns and not TIMESTAMP.
In MySQL the TIMESTAMP is a special auto-updating field and this
confuses EOF's optimistic locking scheme. While you are in there,
also make sure you do not include column types for locking that may
be approximate values (these would include float, double, etc.).
On Nov 13, 2006, at 10:00 AM, Calven Eggert wrote:
> Yes, I commit the changes with myEditingContext.saveChanges().
>
> Since this morning, I have changed the call to
> myEditingContext.invalidateAllObjects to Invalidating the Task
> record, using the method:
>
> NSMutableArray ids = new NSMutableArray();
> ids.addObject(myEditingContext.globalIDForObject(curTask));
> myEditingContext.invalidateObjectsWithGlobalIDs(ids);
>
> This again works, but I discovered that invalidating the
> relationship does not solve the problem. Also discovered that this
> is not a problem in my Oracle database but only using my MySQL
> database. Can anyone shed any light on this?
>
> Still, I am hoping that there is another way to solve this. I'd
> hate to have to invalidate everything every time I make a change.
>
>
>
> On Monday, November 13, 2006, at 09:45AM, "Daniele Corti"
> <> wrote:
>> well, do you commit the database after the first call of
>> assignedTo? I
>> mean if you call yourEditingContext.saveChanges()
>>
>> 2006/11/13, Calven Eggert <email@hidden>:
>>>
>>> Hi all,
>>>
>>> I have a EOEnterpriseObject, called a Task record and it has a
>>> relationship, called AssignedTo, that connects to another
>>> EOEnterprise
>>> record called Identity. In my WO Application, when I assign an
>>> Identity to
>>> the Task record thus creating the AssignedTo relationship, it
>>> works the
>>> first time, but if I do it again immediately after, it then gives
>>> me the
>>> error:
>>>
>>> updateValuesInRowDescribedByQualifier --
>>> com.webobjects.jdbcadaptor.JDBCChannel method failed to
>>> update row in database
>>> com.webobjects.eoaccess.EOGeneralAdaptorException:
>>> updateValuesInRowDescribedByQualifier --
>>> com.webobjects.jdbcadaptor.JDBCChannel method failed to
>>> update row in database
>>> at
>>> com.webobjects.eoaccess.EODatabaseContext._exceptionWithDatabaseCont
>>> extInformationAdded(EODatabaseContext.java:4685)
>>> at
>>> com.webobjects.eoaccess.EODatabaseContext.performChanges
>>> (EODatabaseContext.java:6393)
>>> at
>>> com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditi
>>> ngContext(EOObjectStoreCoordinator.java:415)
>>>
>>>
>>> Just recently getting a basic understanding on how WebObjects
>>> works and
>>> deals with snapshots, thanks to Chuck Hill's book "Practical
>>> WebObjects", I
>>> figured that the snapshot of the Task record, or actually the
>>> relationship
>>> AssignedTo, must not be updated after the first assignment is
>>> set. After
>>> putting in the line EditingContext.invalidateAllObjects(),
>>> the problem went away. I know this isn't the best way to do
>>> this. But I
>>> thought that to-one relationships were suppose to be ok and the
>>> to-many
>>> needed to be babysat. I've also tried
>>> setRefreshesRefetchedObjects(True) but this didn't work, I
>>> assume because I'm not actually going to the db after my save for
>>> a refetch.
>>> I've also tried setDefaultTimestampLag(2) but that didn't work
>>> either.
>>>
>>> Could someone please help me understand what is going on here?
>>> Suggested
>>> readings would also be greatly appreciated.
>>>
>>> Thanks,
>>> Calven
>>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden