On Jun 12, 2013, at 10:32 AM, Chuck Hill <ch...@global-village.net> wrote:
> > 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 Thanks for the appending to the subject - I was just about to do that. Yeah, I am on integration so it could be that there's a new problem. I need to look at the commits. I can tell you what I've done to try to work around it. In ERXPartialInitializer.initializePartialEntities(EOModelGroup): I added some code to explicitly setAttributesUsedForLocking(NSArray) with a Set comprised of locking attributes in the base and partial entity. It doesn't work - in the app right before I save changes, I log out the locking attributes and it still includes a bunch of stuff from the partial entity that aren't set to lock in the model. In a quick scan I can't find any code (other than what I added above) that explicitly sets the locking attributes in the base entity. Tim > >> 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 <li...@thetimmy.com> 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 <ch...@global-village.net> 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 <ch...@global-village.net> 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 <li...@thetimmy.com> 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 <ch...@global-village.net> >>>>>>>> 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
