I'm replying to myself here and updating this thread with more information. I
have a workaround (below) to help with this problem. I still can't say with all
certainty that this issue is not caused by something I've done. I did test some
dumbed-down models/frameworks using the default wonder framework projects. The
issue persisted in my tests.
One illustration of the problem is on attributes using the "boolean" prototype.
If the database value is null or empty the EO is loaded with that attribute
being 'false.' If that boolean is an attribute in the partial entity, it may
end up being considered an attribute to lock on. The generated SQL UPDATE is
adding that attribute to the WHERE clause, e.g.,
<sudo code>
UPDATE foo set some_value="new value" WHERE (foo_id=1234 AND
modify_date='2012-02-14 14:30:15 -0800' AND some_boolean='false')
</sudo code>
The problem here is that you have not chosen someBoolean to be an attribute to
lock on in your model. Further, the value in the database is not actually
'false' - it is empty or NULL. So, the update fails. There are other attribute
types that can have similar issues. Some of this effect can be mitigated
globally updating some null values in the database - but it doesn't really fix
the issue.
Here is a fix I have implemented to get around this issue. Basically I am
strong-arming the attributes for locking to match the model. This is in the
'base' EO.
public void willUpdate() {
super.willUpdate();
EOEntity personEnt = EOUtilities.entityNamed(this.editingContext(),
this.entityName());
personEnt.setAttributesUsedForLocking(new
NSArray(personEnt.anyAttributeNamed("modifyDate"),
personEnt.anyAttributeNamed("personId")));
}
Saves happen normally with this in place. When I have time I plan to continue
poking into ERXPartial to see if there are fixes necessary.
Tim
UCLA GSE&IS
On Jun 12, 2013, at 12:37 PM, Tim Worman <[email protected]> wrote:
> On Jun 12, 2013, at 10:32 AM, Chuck Hill <[email protected]> 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 <[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/lists%40thetimmy.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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
