That did the trick thank you very much... All LOB read tests seem to
be working okay now. I do have an issue with the write test. It's
supposed to write byte[] {6,7,8} but in reality in the database
something more like this gets written: [...@9931579
CLOB reads/writes all seem okay
On 07/12/2010 01:16 PM, Justin Deoliveira wrote:
> Did you register the converters with the factory spi plugin system?
> Looking at the latest from svn:
>
> http://svn.osgeo.org/geotools/trunk/modules/unsupported/jdbc-ng/jdbc-ingres/src/main/resources/META-INF/services/
>
> I don't see any converter spi file.
>
> What you need to do is something similar to oracle:
>
> http://svn.osgeo.org/geotools/trunk/modules/plugin/jdbc/jdbc-oracle/src/main/resources/META-INF/services/org.geotools.util.ConverterFactory
>
> That is create a META-INF/services/org.geotools.util.ConverterFactory
> file in your ingres module, and in it list the fully qualified
> classnames of the convert factories you created.
>
> With that file, the geotools spi plugin system will dynamically load
> your factory classes when org.geotools.util.Converters.convert is called.
>
> Hope that helps.
>
> -Justin
>
> On 10-07-12 10:28 AM, Alex Trofast wrote:
>> Hi Justin,
>>
>> This helps but I'm still a bit uncertain as to how GeoTools will
>> actually tie into the converters... I wrote two, one for Clobs and one
>> for Blobs. But the converters never seem to be triggered...
>>
>> On 07/07/2010 07:14 PM, Justin Deoliveira wrote:
>>> Hi Alex,
>>>
>>> I would suggest you mirror the oracle case. Basically what a "converter
>>> factory" is is sort of an extension point in order to perform conversion
>>> between various types. Essentially teh same idea as commons converters
>>> if you are familiar with them.
>>>
>>> So basically how it works is that the base SQLDialect maps CLOB and BLOB
>>> to String and byte[] respectively. So whenever the JDBCDataStore access
>>> a value from a result set that has the type BLOB, it will always run the
>>> result through the "converter chain". The converter chain essentially
>>> asks all registered converters if it can convert from type a to type b.
>>> In the case of oracle it will ask if any can convert from
>>> oracle.sql.BLOB to byte[].
>>>
>>> Converter implementations are registered via the factory spi mechanism.
>>> Same way datastore factories are. So probably the cleanest solution for
>>> you would be to write a converter that converts ingres Blob and Clob
>>> objects to byte[] and String.
>>>
>>> Hope that helps.
>>>
>>> -Justin
>>>
>>> On 10-07-07 4:51 PM, Alex Trofast wrote:
>>>> Greetings all,
>>>>
>>>> I just converted the LOB test and ran into some issues with it. Ingres
>>>> returns BLOBs with the type code Type.LONGVARBINARY so I mapped that to
>>>> the Blob.class which is the type Ingres returns. Same with CLOBs, the
>>>> mapping is Type.LONGVARCHAR to Clob.class. The test tries to cast the
>>>> Blob.class type to a byte[] and it fails miserably :(
>>>>
>>>> I saw the Oracle driver had OracleBlob/ClobConverterFactory but I am
>>>> uncertain exactly how these work. The Clob/Blob classes will work with
>>>> the getString() method however it is not "recommended" (whatever that
>>>> means in practice) for large streams and you should instead use the
>>>> InputStream methods.
>>>>
>>>> Any help is greatly appreciated, thank you.
>>>>
>>
>
--
Alex
http://bit.ly/geodb
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
