On Jul 26, 2016, at 6:56 AM, Samuel Pelletier <email@hidden> 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 |