On 2013-06-11, at 2:36 PM, Tim Worman wrote: > OK, I have successfully committed a record without an exception but it came > at a big price - so I'm gonna do more testing. So, for: > > entity PERSON > partial entity EMPLOYEE > > I try a single change - setting shouldSync=TRUE > > If I remove the partial entity framework from the build path I can save this > change cleanly. When the partial entity framework is in the build path, it > considers all of the partial entities attributes "locked." They are not in > their model though.
I think that David Aspinall was likely one of the last to work on partials. He is away this week but may be able to shed some light next week. Did a Wonder update cause this? If so, you could also look for recent-ish changes to this in Wonder. Chuck > All the partial's unique attributes show up in the WHERE clause of the UPDATE > statement. One of these is obviously causing the lock error. Example: > > UPDATE PERSON SET should_sync = ? WHERE (person_id = ? AND modify_date = ? > AND comp_time_bal = ? AND emergency_info = ? AND emp_rel_code = ? AND > norm_vac_max is NULL AND out_of_office = ? AND pto_hrs_bal = ? AND > sick_lv_hrs_bal = ? AND start_begin_date is NULL AND start_end_date is NULL > AND start_percent = ? AND vac_hrs_balance = ? AND work_addr_city is NULL AND > work_addr_line1 = ? AND work_addr_line2 is NULL AND work_addr_state is NULL > AND work_addr_zip is NULL)" withBindings: 1:true(shouldSync), > 2:12505(personId), 3:2012-02-14 14:30:15(modifyDate), 4:0.0(compTimeBal), > 5:""(emergencyInfo), 6:""(empRelCode), 7:false(outOfOffice), > 8:0.0(ptoHrsBal), 9:0.0(sickLvHrsBal), 10:0(startPercent), > 11:0.0(vacHrsBalance), 12:""(workAddrLine1)> > > Without the partial entity in the build path, the update statement looks like: > > UPDATE PERSON SET should_sync = ? WHERE (person_id = ? AND modify_date = ?)" > withBindings: 1:true(shouldSync), 2:12505(personId), 3:2012-02-14 > 14:30:15(modifyDate)> > > Which is completely what I'd expect since I only lock on person_id and > modify_date. My assumption is something is wrong in my framework - it > obviously WAS working. I definitely want to rule out a broader problem. > > Thanks, > > Tim > > On Jun 11, 2013, at 1:19 PM, Tim Worman <[email protected]> wrote: > >> Do you mean in your prototype models or in your entity models? I have only >> ever locked on primary key and modifyDate. I know I mentioned in a previous >> thread that this has always worked well. >> >> The FrontBase prototype model only locks on 'id' and 'boolean' attributes. >> The OpenBase attribute model locks every attribute type almost. I'm really >> lost as to what is going on. So, the question is, how can an EO I just >> fetched think it has changed when it has not? >> >> Tim >> >> On Jun 11, 2013, at 9:54 AM, Chuck Hill <[email protected]> wrote: >> >>> In my models, most attributes are locked. >>> >>> Chuck >>> >>> >>> On 2013-06-11, at 9:32 AM, Tim Worman wrote: >>> >>>> 'Locked' is definitely not enabled for those attributes in the model - or >>>> in partial entity that is built on that entity. >>>> >>>> This is the first time I've ever examined the locking in >>>> EOJDBCOpenBasePrototypes. They do look ODD to me. I am using Wonder -> >>>> integration. The MySQL and Oracle prototypes have a ton of locked >>>> attributes as well. >>>> >>>> <PastedGraphic-1.png> >>>> >>>> On Jun 11, 2013, at 8:38 AM, Chuck Hill <[email protected]> wrote: >>>> >>>>> No, I was just trying to think of anything that might alter the WHERE >>>>> from what you would expect looking at the entity in the EOModel. >>>>> >>>>> Have you double checked that locked did not get turned on these >>>>> attributes in the model? Are you using prototypes? Did locking change >>>>> on the prototypes? >>>>> >>>>> >>>>> Chuck >>>>> >>>>> >>>>> On 2013-06-11, at 8:18 AM, Tim Worman wrote: >>>>> >>>>>> Hi Chuck et al: >>>>>> >>>>>> I wasn't sure if maybe I was missing something in your question - so, is >>>>>> this locking behavior I should expect when using partials? I don't >>>>>> recall seeing an update statement like that in the past. >>>>>> >>>>>> Tim >>>>>> >>>>>> On Jun 10, 2013, at 3:38 PM, Tim Worman <[email protected]> wrote: >>>>>> >>>>>>> Thanks Chuck. >>>>>>> >>>>>>> I am using ERXPartials. I've done a couple of deployments including >>>>>>> partial support and it had been working well. This problem just started >>>>>>> recently - really seemed to come out of the blue. The exception is >>>>>>> reproducible in development so there is no other app touching the >>>>>>> database. >>>>>>> >>>>>>> Tim >>>>>>> UCLA GSE&IS >>>>>>> >>>>>>> On Jun 10, 2013, at 3:35 PM, Chuck Hill <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Are you using inheritance or partials? >>>>>>>> >>>>>>>> >>>>>>>> On 2013-06-10, at 3:33 PM, Tim Worman wrote: >>>>>>>> >>>>>>>>> I am suddenly getting strange optimistic locking failures when when >>>>>>>>> updating a row on ec.saveChanges(). At least it seems sudden to me >>>>>>>>> because I can't introspect well enough to see where I caused it. :-) >>>>>>>>> I'm seeing this. >>>>>>>>> >>>>>>>>> Jun 10 15:14:02 eTimesheet[55555] INFO >>>>>>>>> er.transaction.adaptor.Exceptions - Database Exception occured: >>>>>>>>> com.webobjects.eoaccess.EOGeneralAdaptorException: >>>>>>>>> updateValuesInRowDescribedByQualifier -- >>>>>>>>> com.webobjects.jdbcadaptor.JDBCChannel method failed to update row in >>>>>>>>> database. >>>>>>>>> >>>>>>>>> So, I logged at the SQL and capture the userInfo() on the exception. >>>>>>>>> What really caught my eye is the update statement that was produced. >>>>>>>>> The WHERE statement makes it seem like is locking on every attribute >>>>>>>>> in the PERSON entity. My model definitely does not reflect that >>>>>>>>> should be happening. >>>>>>>>> >>>>>>>>> UPDATE PERSON SET campus_mail_code = ?, should_sync = ?, >>>>>>>>> person_first_name = ?, start_end_date = ?, norm_vac_max = ?, >>>>>>>>> student_status = ?, start_begin_date = ?, campus_phone = ?, >>>>>>>>> home_dept_code = ?, person_middle_name = ?, email_address_other = ?, >>>>>>>>> emp_status = ?, work_addr_line2 = ?, emp_rel_code = ? WHERE >>>>>>>>> (person_id = ? AND modify_date = ? AND comp_time_bal = ? AND >>>>>>>>> emergency_info = ? AND emp_rel_code = ? AND norm_vac_max is NULL AND >>>>>>>>> out_of_office = ? AND pto_hrs_bal = ? AND sick_lv_hrs_bal = ? AND >>>>>>>>> start_begin_date is NULL AND start_end_date is NULL AND start_percent >>>>>>>>> = ? AND vac_hrs_balance = ? AND work_addr_city is NULL AND >>>>>>>>> work_addr_line1 = ? AND work_addr_line2 is NULL AND work_addr_state >>>>>>>>> is NULL AND work_addr_zip is NULL) >>>>>>>>> >>>>>>>>> Can anyone help explain the abnormal growth of my WHERE clause? >>>>>>>>> >>>>>>>>> Tim >>>>>>>>> UCLA GSE&IS >>>>>>>>> ________________________________ _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
