Hi Pete, Sorry for the late reply. Here's to your first e-mail:
2013/2/5 Peter Cooner <[email protected]>: > > > > On Tue, Feb 5, 2013 at 10:19 AM, Lukas Eder <[email protected]> wrote: >> >> >> > So I see how the converters can work for tables easily enough - is >> >> > there >> >> > something similar for routines? >> >> >> >> Converters for routines aren't formally supported (yet). As a reminder >> >> to implement this, I have created #2155 >> >> https://github.com/jOOQ/jOOQ/issues/2155 >> >> >> >> You *could* play around with your own routine implementations, by >> >> extending org.jooq.impl.CustomField: >> >> http://www.jooq.org/javadoc/latest/org/jooq/impl/CustomField.html >> >> >> >> Essentially, you'll have to implement jOOQ's internal toSQL() and >> >> bind() methods. The bind() method receives an org.jooq.BindContext, >> >> which exposes the underlying PreparedStatement, so you're free to >> >> properly bind your PG objects. >> > >> > >> > OK, I'm guessing there are examples of this in the source code I could >> > base >> > an implementation off? >> >> Yes. This section of the manual will give you a first impression about >> what you're going to be doing: >> >> http://www.jooq.org/doc/2.6/manual/sql-building/queryparts/custom-queryparts/ >> >> The jOOQ code base is full of examples about how to properly implement >> query parts. >> > > > So let me try and sum this up then - what I'll need to do is > > 1. Create a CustomeField > - That requires a DataType, which is? PostgresDataType.ANY? > 2. Create a CustomTable > - Because the generated Table is bound to a TableField which is an > incompatible type? > 3. Create a CustomRecord > - Because otherwise it wouldn't play right w/ the POJO or anything else? Yes, that's about it. Another option, instead of using the PostgresDataType.ANY might be to hook in your converter for the relevant columns. > Maybe I am looking more for a way to modify the generator? You could try that, but it will certainly mean more work. Do note that there is no strict API guarantee given for the generator API. While I try to keep incompatible changes at a low level, they may happen between minor releases. > This seems like it would be easier if I could somehow help the generator > with its typing problems (if there were some magic support for it, which I > know there is not) ie > > 1. use <customType> to tell generator about a new type, not a convert, but a > new type parser > <customTypes> > <customType> > <name>org.postgis.PGgeometryLW</name> > <parser>gis.PGgeometryLWParser</parser> > </customType> > </customTypes> > 2. use <forcedType> to tell the generator on what columns (or functions) to > use the type on > <forcedTypes> > <forcedType> > <name>org.postgis.PGgeometryLW</name> > <expressions>public.t1.geom_pos</expressions> > </forcedType> > </forcedTypes> Most of jOOQ's JDBC access is pretty standard. There are only a few exceptions to these rules, most of which are done by the official Postgres JDBC driver > I don't know about Oracle, but Postgre's objects all inherit from PGobject, > which you're already parsing, I know I'm missing something obvious here. I don't think you are. The current support for Postgres' PGobject originates from some initial attempts to implement what the Postgres JDBC driver should have implemented already. For instance, the correct way to support user-defined types is through java.sql.Struct or java.sql.SQLData. Unfortunately, that part of the JDBC API is quite clumsy and it is not at all supported by Postgres. In other words, I still think you're breaking new grounds in the combination of jOOQ+PostGIS -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
