On Jul 26, 2016, at 6:56 AM, Samuel Pelletier <[email protected]> wrote: > > Hi Tim, > >>>>>> >>>>>> 1. The new (and very cool) UUID stuff in ERXGenericRecord is NOT opt-in. >>>>>> :-) >>>>> >>>>> I also don’t understand “is NOT opt-in”. To use this, I have to change >>>>> the prototype of the id column from id to uuid. >>>>> >>>>> Of course the migration has to be fixed by hand from: >>>>> personTable.newBlobColumn("id", NOT_NULL); to >>>>> personTable.newUuidColumn("id", NOT_NULL); >>>> >>>> Theodore, >>>> >>>> In my case, the new code runs regardless of how my model is set up. It >>>> runs anytime the primary keys are not cached and “in transaction” is >>>> <true>. With the old behavior nothing happened if “in transaction” was >>>> <true> (with the exception of simply returning the cached keys or null if >>>> not cached). >>>> >>>> The javadoc API hasn’t changed at all. >>> >>> If you’ve observed a change that you haven’t opted in for, then it could be >>> a bug. Could you describe it all more fully, and open a GitHub issue? >> >> Issue #1 was addressed by a subsequent patch which checks for a null >> prototypeName() on the primary key attribute(s). >> >> Issue #2 I could use some feedback. I would not have experienced the bug at >> all if prototypeName() wasn’t returning null even though the attribute in >> question has a prototype designated. > > For issue #2 there was 2 things discussed, the first one is the fact > rawPrimaryKeyDictionary() return a PK even if inTransaction is false. I've > done that because I interpreted the inTransaction false as "I do not want to > trigger a DB transaction to get my PK" instead of "I do not want to create > new PK”.
From the javadoc: @param inTransaction * boolean flag to tell the object if it is currently in the * middle of a transaction My take is that it is “I am already in the middle of a transaction <true>, just return whatever we already have without digging". The javadoc says the the only class that calls with <true> is ERXDatabaseContextDelegate - which I think only occurs on saveChanges with a newly inserted EO. @return primary key dictionary for the current object, if the object does * not have a primary key assigned yet and is not in the middle of a * transaction then a new primary key dictionary is created, cached * and returned So, in transaction, with no primary key yet assigned, nothing happened in the prior implementation. So, my concern would be that there is a new undocumented behavior when inserting a new object and ERXDatabaseContextDelegate calls ERXGenericRecord.rawPrimaryKeyDictionary. I have some thoughts on this and I’ll submit a patch for review. > For the prototypeName() not returning the attribute prototype, I did not > played with the prototypeName() method. If you can provide more details on > how to replicate we may be able to understand the cause. > > Samuel Yeah, my users have a page to insert new line item EO’s in a repetition. On insertion, ERXDatabaseContextDelegate.databaseContextNewPrimaryKey calls ERXGenericRecord.rawPrimaryKeyDictionary. Apparently, at this point each EOAttribute of the EOEntity is returning null for prototypeName() - including the primary key attr. Unfortunately, I can’t understand why that would be because prototypes are obviously assigned. I do have my own base class that inherits from ERXGenericRecord but even when I remove it, this condition still occurs. Anyone have any thoughts on this? 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]
