Hi Chuck, On 5 Mar 2016, at 5:19 am, Chuck Hill <[email protected]> wrote:
> I missed something. You could make a JDBCPlugIn subclass, override > jdbcInfo() and add the definition for citext to what super returns. A lot of > the existing plugins do this. That is not difficult to do and you define > the plugin class in the model connection dictionary. That is probably the > cleanest most reliable solution. This works, and as you say it’s much nicer than hacking around in the migration’s upgrade() method. It’s essentially the same code as I posted earlier, though operating on the jdbcInfo dictionary rather than the connectionDictionary. Neat solution—thanks for steering me into it, Chuck. Having overridden jdbcInfo(), it’s interesting to see how many times that gets called during launch: a couple of times at the start of migrations, and then once per migrating model. And it would seem to be getting the JDBC info from the database each time, because after the Ident migration in which we add the CITEXT extension, the next call to jdbcInfo() in my subclass finds the CITEXT entry in the dictionary from super.jdbcInfo(). That is, this must be perilously close to working out of the box, without subclassing PostgresqlPlugIn. It’s not obvious why the very next migration (that touches an entity with a CITEXT attribute) would be the one that fails without the subclass’s behaviour, then, but I’m going to leave it there now since this is all working nicely. -- Paul Hoadley http://logicsquad.net/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
