[SqueakDBX] Character encoding and pooling in SqueakDBX and Glorp
Mariano Martinez Peck
marianopeck at gmail.com
Thu Aug 26 19:43:12 UTC 2010
On Wed, Aug 25, 2010 at 7:20 AM, Panu Suominen
<panu.j.m.suominen at gmail.com>wrote:
> 2010/8/24 Mariano Martinez Peck <marianopeck at gmail.com>:
> > Yes. So that I can see it. Do you know if it breaks compatibility with
> > databases or OS? because SqueakDBX classes like DBXConnection should be
> > cross-backend.
> I don't know how cross-platform my fix is. Database part should be
> fine. Postgresql can now detect the encoding.
Thanks a lot for the changeset. Now I will test with different OS and
databases and I will let you know.
now a couple of questions:
- I guess a lot of people doesn't need UTF (or other) encoding. And I guess
that the transformation brings some overhead in the query result mosty...(I
should run the benchmarks and see if there is difference). But I was
thinking if we could make this optional. I like the code and design you did.
I think that a good idea would be to add some kind of NullEncoder which is
DBXConnection >> initialize
instead of TextConverter newForEncoding: #utf8.
Then, for postgres, you will be using the one from TextConverter
newForEncoding: (r rows first valueAt: 1).
Even more, I would like to make it optional. Maybe we can create
DBXCOnnection class >> platform: aPlatform settings: aConnectionSettings
and that will do:
platform: aPlatform settings: aConnectionSettings encoder: anEncoder
Finally, the cleint code (your app code) creates the connection with that
or something like that....but the idea of making it optional not to have
overhead if not required, and being able to be enabled from the app code.
- What happens is the database supports and specific encoding that Pharo
TextConverter newForEncoding: (r rows first valueAt: 1).
will return nil, causing UndefinedObject dnu something.
maybe we can just set again the NullEncoder in that case? or raise an error
? what do you think?
Others database platforms just don't know anything about encoding
> (they use default utf-8). If other smalltalk dialects have
> TextConverter then it should be fine.
> If they haven't then I can implement another abstraction layer to
> provide compatibility between dialects.
> > If you want to can use another new package with your commit.
> I am sorry, but I did not quite understand what you meant...
> Unfortunately I am a little busy at work right now so I did not had
> time to learn how to use monticello properly to create version only
> containing required changes.
> For this reason I attached change set file to this mail.
Don't worry :)
> >> Also is there a connection pooling facility for SqueakDBX or Glorp?
> > Yes, several.
> Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SqueakDBX