I took a look at the FrontBase plugin. It’s also pretty straight forward with one exception.
override FrontBasePlugIn.schemaCreationStatementsForEntities(NSArray entities, NSDictionary options) Moving to the newer API requires passing in a EOSchemaGenerationOptions instead of NSDictionary. In this case there is a mechanism to message a default in where an option is null in the dictionary. This will be tougher with EOSchemaGenerationOptions since it merely returns booleans for desired options. Surprisingly, it doesn’t implement NSKeyValueCodingAdditions. Tim UCLA GSE&IS On May 27, 2014, at 2:41 PM, David Avendasora <webobje...@avendasora.com> wrote: > Wow Tim! > > Very cool! I’m going to pull this into one of my projects and check it out - > I started down this road with one or two of the plugins, but I didn’t get > this far. Hopefully I can add my plugin changes to this and we can have a > nice “modernization" (2008ish) of Wonder! > > Dave > > On May 27, 2014, at 5:03 PM, Timothy Worman <li...@thetimmy.com> wrote: > >> David et al: >> >> Sorry to reply to myself. Fixed. Migrations, etc., are now working for me >> with everything updated to the WO 5.4 API’s. I have branch of wonder called >> ‘worman’ which has the changes. Here is the diff: >> >> https://github.com/timsquared/wonder/commit/3b39cfc00fcb9327931d8fe5835442c9ca1e1327 >> >> Database plugins MAY need to be updated - but maybe not. :-) >> >> Tim >> UCLA GSE&IS >> >> On May 27, 2014, at 11:23 AM, Timothy Worman <li...@thetimmy.com> wrote: >> >>> Hey Dave: >>> >>> I saw that you had a similar post to the list about the older deprecated >>> API’s. >>> >>> Yeah, I’ve jumped in that pool - SQLHelper and all. I have a branch of >>> Wonder that is completely updated off of the older, deprecated API’s. If >>> you’re interested in checking it out, I can make it available on github. >>> >>> I’m still seeing ERXMigrationDatabase.synchronizationFactory returning a >>> com.webobjects.eoaccess.EOSynchronizationFactory - which makes me concerned >>> that something down deep and unreachable by me is making that happen. >>> >>> Curiously, this stuff is correct: >>> >>> expression class: >>> com.webobjects.jdbcadaptor.OpenBasePlugIn$OpenBaseExpression >>> plugin name: OpenBase >>> >>> I’ve been away all weekend too so I haven’t been able to look into it >>> further. Let me know if you’d like to hammer on this thing a little. >>> >>> Tim >>> UCLA GSE&IS >>> >>> On May 24, 2014, at 9:00 AM, David Avendasora <webobje...@avendasora.com> >>> wrote: >>> >>>> Hi Tim, >>>> >>>> In addition to the schema synchronization stuff you also need to look at >>>> the SQLHelper subclasses defined for the plug-in. >>>> >>>> I believe these were created as part of Mike's original migrations >>>> implementation and it's entirely possible that there was never one created >>>> for open base and therefore it's not doing what it supposed. >>>> >>>> Sorry I can't be more specific right now I'm not in front of my computer, >>>> but I've been digging around down in the plug-ins and the schema >>>> synchronization code quite a bit in the last couple months so I think I'll >>>> should be able to help more once I am back at my computer. By Tuesday for >>>> sure. >>>> >>>> Dave >>>> >>>> Sent from my iPhone >>>> >>>>> On May 23, 2014, at 7:26 PM, Timothy Worman <li...@thetimmy.com> wrote: >>>>> >>>>> So, I’ve been looking into a problem with ERXMigrations related to >>>>> OpenBase. The SQL in migrations is wonky which was detailed here many >>>>> moons ago: >>>>> >>>>> http://prod.lists.apple.com/archives/webobjects-dev/2008/Oct/msg00431.html >>>>> >>>>> Namely, the “constraints” sql-isms are different. But wait, aren’t the >>>>> frameworks supposed to build SQL expressions based on the JDBC plugin >>>>> you’re using (in this case OpenBasePlugIn)? >>>>> >>>>> I decided to mess with the OpenBase plugin source and see if I could fix >>>>> this issue - maybe sth more recent in WO-ness wasn’t being properly >>>>> overridden in the plugin. This is what I’ve found - >>>>> >>>>> ERXMigrationDatabase.synchronizationFactory() is supposed to return a >>>>> database-specific subclass of EOSynchronizationFactory (if I’m not >>>>> mistaken). For OpenBase this should be OpenBaseSynchronizationFactory. >>>>> However, it doesn’t appear to. The first time I run my app and >>>>> ERAttachment0 is called, a standard base EOSynchronizationFactory (not >>>>> OpenBaseSynchronizationFactory) is returned. No code from the subclass is >>>>> called. >>>>> >>>>> Do others using PostgreSQL or other database experience this? >>>>> >>>>> Bueller…….Bueller…… >>>>> >>>>> 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/webobjects%40avendasora.com >>>>> >>>>> This email sent to webobje...@avendasora.com >>>> >>> >>> >>> _______________________________________________ >>> 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/lists%40thetimmy.com >>> >>> This email sent to li...@thetimmy.com >> >> >> > > > ————————————————————————————— > WebObjects - so easy that even Dave Avendasora can do it!™ > ————————————————————————————— > David Avendasora > Senior Software Abuser > Nekesto, Inc. > > > > > > _______________________________________________ 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
