Re: Migrations auto-run issue with shared Entities
Re: Migrations auto-run issue with shared Entities
- Subject: Re: Migrations auto-run issue with shared Entities
- From: David LeBer <email@hidden>
- Date: Thu, 25 Oct 2012 18:14:39 -0400
On 2012-10-25, at 6:03 PM, Chuck Hill <email@hidden> wrote:
> Poor David. So many bullets. So few toes.
Fixed that for you.
>
>
>
> On 2012-10-25, at 2:56 PM, David Avendasora wrote:
>
>> Oh dear mother of God!
>>
>> I never issued a pull request for this, and it's a Good Thing™ I didn't. It has a serious flaw. Basically, the following line in migrationsDidRun :
>>
>> EOSharedEditingContext sharedEC = EOSharedEditingContext.defaultSharedEditingContext();
>>
>> Should be:
>>
>> EOSharedEditingContext sharedEC = EOSharedEditingContext._defaultSharedEditingContext();
>>
>> Notice the under-bar at the beginning of the static method name. The call without the under-bar is not just an accessor, it lazy initializes the ivar as well. So if you, like we, are using Migrations, had been using the EOSharedEditingContext and have since decided to rid yourselves of its particular brand of evil by calling:
>>
>> EOSharedEditingContext.setDefaultSharedEditingContext(null);
>>
>> in the Application class constructor, the lack of that under-bar will undo setting the default SEC to null by reinitializing the default SEC as soon as migrations finish. This, of course, means that all new EOEditingContext instances will hold a pointer to it.
>>
>> Because the the call to ERXDatabaseContext.loadSharedObjects(sharedEC); may now pass null, you'll need to handle that situation properly.
>>
>> Dave
>>
>> On Jul 18, 2012, at 1:18 AM, Ramsey Gurley <email@hidden> wrote:
>>
>>>
>>> On Jul 16, 2012, at 7:29 PM, David Avendasora wrote:
>>>
>>>> Hi Robert and Johan,
>>>>
>>>>
>>>> What? Still here? You have a strong masochistic streak? Well, okely dokely then, here we go:
>>>>
>>>> I have a patch but unfortunately it's really not ready for prime-time, but I've included the code (as-is) below.
>>>>
>>>> The core piece of it is to modify ERXApplication#migrationsWillRun(ERXMigrator) and ERXApplication#migrationsDidRun(ERXMigrator) as follows:
>>>>
>>>> private boolean _isSharedObjectLoadingEnabledCachedValue;
>>>>
>>>> protected void migrationsWillRun(ERXMigrator migrator) {
>>>> _isSharedObjectLoadingEnabledCachedValue = ERXDatabaseContext.isSharedObjectLoadingEnabled();
>>>> if (EODatabaseContext.isSharedObjectLoadingEnabled()) {
>>>> EODatabaseContext.setSharedObjectLoadingEnabled(false);
>>>> }
>>>> }
>>>>
>>>> protected void migrationsDidRun(ERXMigrator migrator) {
>>>> if (_isSharedObjectLoadingEnabledCachedValue) {
>>>> EODatabaseContext.setSharedObjectLoadingEnabled(true);
>>>> EOSharedEditingContext sharedEC = EOSharedEditingContext.defaultSharedEditingContext();
>>>> ERXDatabaseContext.loadSharedObjects(sharedEC);
>>>> }
>>>> }
>>>>
>>>> But unfortunately, because the initial database access occurred while shared object loading was disabled, now EOF won't automatically load the shared objects for you. You have to manually load it. I've added the method below to ERXDatabaseContext. It will load/reload all the shared entities (you can see I call it as the last thing in the migrationsDidRun method above).
>>>>
>>>> public static final String FETCH_ALL_FETCH_SPEC_NAME = "FetchAll";
>>>>
>>>> /**
>>>> * Method to manually load (or reload) all shared EOs by iterating through all the models
>>>> *
>>>> * @param sharedEC
>>>> *
>>>> * @author David Avendasora
>>>> * @since Jul 13, 2012
>>>> */
>>>> public static synchronized void loadSharedObjects(EOSharedEditingContext sharedEC) {
>>>> EOModelGroup modelGroup = EOModelGroup.defaultGroup();
>>>> NSArray<EOModel> models = modelGroup.models().immutableClone();
>>>> for (EOModel model : models) {
>>>> String modelFileName = model.name() + ".eomodeld";
>>>> NSArray<EOEntity> entitiesWithSharedObjects = model.entitiesWithSharedObjects().immutableClone();
>>>> for (EOEntity entity : entitiesWithSharedObjects) {
>>>> String entityFileName = modelFileName + File.pathSeparator + entity.name() + ".plist";
>>>> NSArray<String> sharedObjectFetchSpecNames = entity.sharedObjectFetchSpecificationNames();
>>>> if (sharedObjectFetchSpecNames.containsObject(FETCH_ALL_FETCH_SPEC_NAME)) {
>>>> sharedObjectFetchSpecNames = new NSArray<String>(FETCH_ALL_FETCH_SPEC_NAME);
>>>> }
>>>> for (String fetchSpecName : sharedObjectFetchSpecNames) {
>>>> String fetchSpecFileName = modelFileName + File.pathSeparator + entity.name() + ".fspec";
>>>> EOFetchSpecification fetchSpec = entity.fetchSpecificationNamed(fetchSpecName);
>>>> if (fetchSpec != null) {
>>>> // no need to lock because the
>>>> // bindObjectsWithFetchSpecification(EOFetchSpecification, String)
>>>> // method is thread safe.
>>>> sharedEC.bindObjectsWithFetchSpecification(fetchSpec, fetchSpecName);
>>>> }
>>>> else {
>>>> log.warn("Problem found in Entity \"" + entity.name() + "\": \""
>>>> + fetchSpecName + "\" is listed in the \"sharedObjectFetchSpecificationNames\" element of the \""
>>>> + entityFileName + "\" file, but there is no corresponding \""
>>>> + fetchSpecName + "\" element in the \""
>>>> + fetchSpecFileName + "\" file.");
>>>> }
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
>>>> I'm not 100% sure I'm doing the right thing with regards to loading the modelGroup and models … I'm not as comfortable down at this level of EOF as I probably should be. It works, but it might now work for everyone.
>>>>
>>>> Now if I could just scrub hard enough to get this dirty feeling to go away.
>>>>
>>>> Dave
>>>>
>>>> On Jul 15, 2012, at 2:30 PM, Johann Werner wrote:
>>>>
>>>>> I saw a patch for exactly that problem recently in the fork of amagavi. Hopefully there will be a pull request soon (hi David, are you reading this ;-)
>>>>>
>>>>> jw
>>>>>
>>>>>
>>>>> Am 15.07.2012 um 07:52 schrieb Mr. Robert Hanviriyapunt:
>>>>>
>>>>>> I had some issues with Migrations just now when I made an entity Shared. The application started up and attempted to load the shared entity before Migrations could create the table for it. Anyone else had the same problem? My work around was to de-select Shared for the entity, start up the application, stop the application, re-select Shared for the entity, then re-start the application. Gonna be a pain if I have to do this on for a deploy to a stage or prod environment tho.
>>>>>>
>>>>>> = Robert =
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>>>
>>>>>
>>>>
>>>>
>>>> —————————————————————————————
>>>> WebObjects - so easy that even Dave Avendasora can do it!™
>>>> —————————————————————————————
>>>> David Avendasora
>>>> Senior Software Abuser
>>>> Kaiten, Inc.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>> —————————————————————————————
>> WebObjects - so easy that even Dave Avendasora can do it!™
>> —————————————————————————————
>> David Avendasora
>> Senior Software Abuser
>> Kaiten, Inc.
>>
>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
> http://www.global-village.net/gvc/practical_webobjects
>
> Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest Growing Companies in B.C!
> Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of Canada’s Fastest-Growing Companies by PROFIT Magazine!
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden