Re: [patch] add CLOB datatype
Franck Routier <franck.routier <at> axege.com>
2012-04-26 12:55:31 GMT
Ok. So I'll fix this.
What I have done is :
1) allow user to choose a maxAutoRetrieveSize, to (eventually) avoid
getting all content when building the SRecordInstance
2) tweak Prostgresql, CachéDB and Mysql driver (to get the right
sql type, eg TEXT or LONGVARCHAR)
3) add a test in DataTypeTest
1) Postgresql does not really support Clobs.
This would map to TEXT fields, but the streaming part is not
implemented, and the whole text will be in the resultset anyway.
2) I was not able to find a way to allow interaction with the Clob
Maybe with another SFieldXXXX that would have an internal type
java.sql.Clob (but then you could only interact while within the
transaction as I understand it).
Anyway, it's probably not very useful for now.
I have added a test case, but I have no Oracle database to test it
now. Anyone willing to test is welcome.
Le 26/04/2012 11:41, Noel Grandin a écrit :
You know, you are right, that loop does look dodgy.
To be honest, my code only briefly used CLOB's and then I moved
onto something else, so that code is no longer in use here.
On 2012-04-24 12:18, Franck Routier wrote:
But, then maybe we should give the user (I mean the developper
using Simpleorm) an access to the Clob object, instead of
fetching its value on queryFieldValue ?
And maybe add a custom method to SFieldClob that would
effectively fetch the value, but not on queryFieldValue ?
Another point is, did this code work ? I'm asking because the
break condition in queryFieldValue seems erroneous, as
reader.read(buf) will return -1 on end of file, not 0. ?
Le 24/04/2012 11:12, Noel Grandin a écrit :
No good reason, just that it would be a little surprising
performance wise - could trigger a very long fetch from the
server that is likely to be uncached.
But I don't have a principled objection to it.
On 2012-04-24 09:12, Franck Routier wrote:
Hi Noël and Anthony,
I've been looking at your code, and I was wondering
why Clobs wouldn't be comparable... What is the
reason behind that ?
Typically, Postgresql type for Clobs (TEXT) would
just compare fine, as well as java representation of
a Clob (a String).
Is there any Oracle specificity around that, or
simply a size problem ??