Hola from CA: Following up and looking for advice on this. I did follow this approach (below) for naming of the OpenBasePlugIn class. I’ve added some new expressions to the OpenBaseSynchronization factory to support functions that are missing for migrations. So, in a migration where you alter the column type, you’d call this:
ERXMigrationColumn.setDataType(). In that method are these calls: EOSchemaSynchronization schemaSynchronization = (EOSchemaSynchronization) _table.database().synchronizationFactory(); NSArray<EOSQLExpression> expressions = schemaSynchronization.statementsToConvertColumnType(_name, _table.name(), null, new _ColumnType(externalType, scale, precision, width), options); The sync factory that is returned is an instance of OpenBasePlugIn$OpenBaseSynchronizationFactory. However, the statementsToConvertColumnType that I added to the update OpenBaseSynchronizationFactory isn't called. This makes me think it is still referencing the OpenBasePlugIn that is part of the WO 5.4.3 distribution. App launch fails with: “Your EOSynchronizationFactory does not support the required 'convert column type' operation." Any thoughts on why the newer plugin with changes might not be getting called? Is it possible that migrations are running before the newer plugin is loaded into the classpath? Tim UCLA GSE&IS On May 28, 2014, at 1:42 PM, Chuck Hill <ch...@global-village.net> wrote: > The replacement plugins are in ERExtensions which is forced into the class > path before any of the WO frameworks. As such any classes that they contain > that have the same package and class names as in WO proper will render the > original classes invisible to the JVM. > > Chuck > > > > On 2014-05-28, 1:13 PM, "David Avendasora" wrote: > > All of the other PlugIns (Oracle excluded) seem to use the same name as the > one included in the WO binaries, but I do see your point about it possibly > causing confusion for all the WO developers out there using OpenBase. > > … > > … > > … > > snk. snrk. cough. cough… > > Okay, seriously though, I think it would be best to use the expected name > (OpenBasePlugIn) and use the same mechanisms that the other DB plugins use to > keep there from being conflicts. > > Now, let me get back to my servlet-based D2JC project with vertical > inheritance and sharedEC on SQLServer. > > Which reminds me, somewhere around here I have Chuck’s MicrosoftPlugIn… I > should look at updating that and getting it into Wonder, too - as I promised > I would … a couple years ago. > > :-) > > Dave > > > On May 28, 2014, at 12:27 PM, Timothy Worman <li...@thetimmy.com> wrote: > > I received permission to include a modified OpenBasePlugIn into Wonder. > Thought I’d open this up to a best practice discussion here. Since the > original plugin was bundled with the WO frameworks, my assumption is that the > plugin class should be renamed - sth like EROpenBasePlugIn? By doing so we > could eliminate any possible confusion. > It was communicated to me that the plugin was an enhanced version of the one > that shipped with WO. I have modified it to correct immediate issues with > migrations in Wonder (including updates to WO 5.4 synchronization classes). > This would also make it somewhat dependent on a version of Wonder that has > been updated in the same fashion - which I also have and, if it passes > muster, could be pulled into Wonder as well. > 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 > > > ————————————————————————————— > 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/chill%40global-village.net > > This email sent to ch...@global-village.net
_______________________________________________ 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
