Well, and this is from left field as I have at least a half dozen apps I have 
written.
One huge app, and a bunch of great publish to rest type apps. I have never 
touched the locks.

I haven't even had any problems, until now.

Relationships weren't relating, and locks were coughing back exceptions.

Finally, I created a new database from migration. Removed all locks everywhere 
except for modtime. Hey this is mysql
and there will only be a half dozen users. Basically a REST publisher for 
filling up iOS apps.

Then data sychn'd the old data back into the new database. And it works. 
However, I did this a few times and until
I unlocked almost everything did it work. 

Very perplexing. But good enough for now to get this puppy publishing data.

Thanks
James



On Jan 12, 2012, at 2:20 PM, Ramsey Gurley wrote:

> 
> On Jan 12, 2012, at 11:09 AM, James Cicenia wrote:
> 
>> This has been very informative. I am using mysql. This was an application 
>> that suddenly went "corrupt"... on my development. 
>> 
>> I did some migrations, changed some relationships,
> 
> I don't think this is it either, but something to look out for... MySQL can't 
> do circular relationships with foreign key constraints.  It cannot defer the 
> constraints until the end of the transaction. Maybe you created a circular 
> relationship while editing your model? Are you ordering your transactions in 
> MySQL to account for fk constraints that aren't circular but might be out of 
> order?
> 
> com.webobjects.eoaccess.ERXEntityDependencyOrderingDelegate.active=true
> 
> BTW, Postgresql can do deferred FK constraints :-)
> 
>> the usual, and then bam! Won't update or edit this one entity. HOWEVER,
>> another clue emerged.. if I try to add a new record, it never completes the 
>> to-one relationship to Author. 
>> 
>> I will remove all locks, rebuild, etc. and see what happens. Nonetheless, I 
>> do like just putting one lock in place on a version number.
>> 
>> Onwards with my other custom report project.
>> 
>> James
>> 
>> 
>> 
>> On Jan 12, 2012, at 12:01 PM, Ruenagel, Frank wrote:
>> 
>>> Yeah,  MSSQL is definitely one of these databases. IIRC, it is a problem of 
>>> the default MS plugin.  James, do you use SQL-Server with the default MS 
>>> Plugin of WO? 
>>> 
>>> But also I think that the  problem is not an optimistic locking problem.  
>>> James, if you do not have access to the userInfo of the exception, simply 
>>> remove all
>>> locking-symbols in the Entity in EO Modeler (include the entities joined).  
>>>  Rebuild. Does the exception appear again? If yes then it is *not* due to 
>>> opt  locking.
>>> 
>>> "Optimistic Locking" in standard EOF is simply  realized with a where 
>>> clause in the update sql-string: the values  expected  are compared  with 
>>> the real data in the rows.
>>> It could be helpful to view the sql code, which is sent to your database 
>>> while updating. 
>>> 
>>> Switch on logging of the sql with : 
>>> 
>>> NSLog.allowDebugLoggingForGroups(NSLog.DebugGroupDatabaseAccess); 
>>> 
>>> Then try to execute the logged sql manually.
>>> 
>>> Good luck.
>>> 
>>> Frank
>>> 
>>> Von: [email protected] 
>>> [mailto:[email protected]] Im 
>>> Auftrag von Ramsey Gurley
>>> Bereitgestellt: Donnerstag, 12. Januar 2012 17:26
>>> Bereitgestellt in: WebObjects
>>> Unterhaltung: Can someone explain the locks?
>>> Betreff: Re: Can someone explain the locks?
>>> 
>>> A date time is actually a bad attribute to lock on some databases.  
>>> Timestamps have nanosecond resolution, but some databases are not that 
>>> accurate.  So you end up with a value that is slightly off from what is 
>>> stored resulting in locking exceptions.  I think MSSQL is one of these 
>>> databases.
>>> 
>>> But to get to your point, yes you can do that.  Locking says that this 
>>> attribute value is important.  If you lock a single column and update it 
>>> every time you save in willUpdate() you're saying that ALL attribute 
>>> changes are important.  
>>> 
>>> However, you then become dependent on application logic doing that.  If 
>>> someone comes in and edits values with a DB tool and does not increment the 
>>> 'version' column, then those changes can get wiped out by a save from the 
>>> app.
>>> 
>>> In your case, unless it's the timestamp thing, I don't *think* locking is 
>>> your problem, because you're the only person editing the data.  When you 
>>> get the exception, if you do a select in the database with the qualifier 
>>> values, does it return the row?  If it does, then it's probably not a 
>>> locking exception.
>>> 
>>> Ramsey
>>> 
>>> 
>>> On Jan 12, 2012, at 9:11 AM, James Cicenia wrote:
>>> 
>>> 
>>> Ok --
>>> 
>>> So, why would I need more than one lock? Why not just a modified date?
>>> 
>>> James
>>> 
>>> PS: "legacy" Been awhile since I have been to apples docs. Not a good thing 
>>> to first show a client!
>>> 
>>> 
>>> On Jan 12, 2012, at 9:51 AM, Ramsey Gurley wrote:
>>> 
>>> 
>>> 
>>> On Jan 12, 2012, at 8:33 AM, James Cicenia wrote:
>>> 
>>> 
>>> Hello -
>>> 
>>> Ok, this update / add entity problem is driving me a little nuts.
>>> If I add a new record, it won't recognize the related record that was 
>>> picked, and won't save.
>>> If I edit any existing record and do nothing but hit save... bam.. row diff 
>>> error!
>>> 
>>> So, that got me to exploring those little black locks that I never, ever 
>>> worried about, or changed!
>>> 
>>> But now that I have focused on them.. what the heck do they really mean or 
>>> do?
>>> 
>>> http://developer.apple.com/legacy/mac/library/documentation/WebObjects/UsingEOModeler/4WorkingWithAttributes/WorkingWithAttributes.html#//apple_ref/doc/uid/TP30001018-CH204-BABBDEIE
>>> 
>>> 
>>> 
>>> If I save a record
>>> it should save.. locks be damned. So, I figured it has to do with 
>>> "optimistic" locking. But what?
>>> 
>>> Should I leave the default set? Should I delete all and improve 
>>> performance? 
>>> 
>>> 
>>> Wondering
>>> James _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list      ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/ramseygurley%40gmail.com
>>> 
>>> This email sent to [email protected]
>>> 
>>> 
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list      ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com
>>> 
>>> This email sent to [email protected]
>>> 
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list      ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/james%40jimijon.com
>>> 
>>> This email sent to [email protected]
>> 
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list      ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com
>> 
>> This email sent to [email protected]
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to