Re: H2 plugin and prototypes
Re: H2 plugin and prototypes
- Subject: Re: H2 plugin and prototypes
- From: Ramsey Gurley <email@hidden>
- Date: Fri, 22 Jun 2012 10:24:50 -0700
On Jun 22, 2012, at 10:10 AM, Johann Werner wrote:
>
> Am 22.06.2012 um 18:50 schrieb Ramsey Gurley:
>
>>
>> On Jun 21, 2012, at 11:12 PM, Johann Werner wrote:
>>
>>> Hi list,
>>>
>>> working with the H2 plugin I got an interesting issue with prototypes. Looking at ERPrototypes there is an entity EOJDBCH2Prototypes so I assume that adding my own prototypes should have an entity named EOJDBCH2CustomPrototypes. Now I have tracked down that during access of a model the prototypes for this model are created after calling ERXEOAccessUtilities.guessPluginNameForConnectionDictionary().
>>>
>>> The H2 plugin needs only the URL field in the connection dictionary (e.g. jdbc:h2:mem:myDB) so it will look up the class name that has been registered for the h2 prototcol. That class is ERH2PlugIn from which the "PlugIn" part is subtracted leaving "ERH2". That means that WO looks for a EOJDBCERH2Prototypes which of course doesn't exist falling back to EOJDBCPrototypes which gives wrong external data types.
>>>
>>> A solution would be to not only strip off a trailing "PlugIn" but also a leading "ER", this would affect the H2 and the Derby plugin. What makes me wonder is that apparently no one had this problem before. Changing the mentioned method would make WO look for a differently named prototype entity so it could break for some. Are there any objections against that modification? It seems that guessing a name "ERH2" instead of "H2" should be wrong.
>>>
>>> jw
>>
>> Smells bad. Parsing for magic strings is gross. Have you tried registering the H2PlugIn class instead of the ERH2PlugIn class in the h2 principal class? Seems like that should work.
>
> That is from the Derby plugin that has the very same class structure:
>
> /**
> * 5.4 declares the same class name for the DerbyPlugIn. If your classpath isn't
> * exactly right, they'll win, so we pushed the real code into ERDerbyPlugIn and
> * we set a custom principal class that registers the ER variant that is
> * "guaranteed" to not have collisions as the plugin for the "derby"
> * subprotocol.
> *
> * @author hprange guided by mschrag
> */
>
> So I think using H2PlugIn instead of ERH2PlugIn is not a good idea either.
Did you try it?
Ramsey
_______________________________________________
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