There are always two possible mechanisms for combining the data type with the SQL statement. We can bind it, in which case the driver is responsible for any conversion, and quite possibly it's being converted into some sort of binary representation. Or we can write it inline in the query as a string. So the VisualWorks drivers would be responsible for doing any conversion if we do binding, but it's true that we need to be responsible if we want to do it as a string.
In Postgresql, at least in VisualWorks, it's a bit confusing, because the Postgresql driver basically doesn't support binding - or at least what it does for binding is insert the literal into the string. That's more expensive, and just ends up the same, so normally I wouldn't use binding on Postgresql. But the bottom line is that yes, we do need Glorp to be able to do this at its level, and the OpenDBX driver would only be involved if someone was using binding. On Fri, Nov 11, 2011 at 7:33 AM, Guillermo Polito <[email protected] > wrote: > > > On Fri, Nov 11, 2011 at 8:16 AM, Mariano Martinez Peck < > [email protected]> wrote: > >> Hi guys. I am trying to understand how to integrate this in the OpenDBX >> driver, but I am a little bit lost. >> First, I don't understand when this #byteArrayToSQLStringConverter is >> used. What is the bytearray and what is the string? one is the database >> type and the other one is the inst var of one you your mapping class? >> > > This is because the conversion is being done right now in glorp... We are > already performing conversions in OpenDBX, but they are not platform > specific conversions, since we handle only ANSI conversions ;). > > Maybe we can build a PostgreSQLOpenDBXDriver (?) > > >> >> Second, I don't know WHERE to put such conversion in the OpenDBX driver. >> Why it should be there if #convertSQLStringToByteArray: aString for: aType >> will continue to exist in Glorp. So it means I should also modify Glorp? >> >> How does the EXDI driver of VW work here? >> >> Thanks! >> >> >> On Thu, Nov 10, 2011 at 11:15 AM, Henrik Sperre Johansen < >> [email protected]> wrote: >> >>> On 10.11.2011 14:29, Sven Van Caekenberghe wrote: >>> >>>> Alan, >>>> >>>> On 09 Nov 2011, at 21:20, Alan Knight wrote: >>>> >>>> My inclination would be to think that this is something that the >>>>> database driver ought to be handling rather than having it in Glorp at >>>>> all. >>>>> But, given that it's in there, I suppose it's not unreasonable. >>>>> >>>> Well, I just extended the previous conversion that was already located >>>> there. I did not consider whether or not that kind of platform specific >>>> code was in its right place, architecture wise. >>>> >>>> So, will it be integrated somewhere ? If it is only integrated in the >>>> Pharo/Squeak port that is fine for me too, but it would be frustrating if >>>> it got lost on the next upstream integration. >>>> >>>> I would just love to be able to load the standard release and have it >>>> working for me (i.e. loading blobs from a recent PostgreSQL). >>>> >>>> Thx for the reply, >>>> >>>> Sven >>>> >>>> I agree with Alan, it should be in the Postgres-specific code of >>> OpenDBX-driver. >>> Glorp can't be the only user who wants to read blobs, can it? ;) >>> >>> Cheers, >>> Henry >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "glorp-group" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/glorp-group?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "glorp-group" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/glorp-group?hl=en. >
