[SqueakDBX] Character encoding and pooling in SqueakDBX and Glorp

[Mariano Martinez Peck]

On Fri, Aug 27, 2010 at 8:10 AM, Panu Suominen
<panu.j.m.suominen at gmail.com>wrote:

> Thank you for excelent feedback.
>

thanks for your changes :)


>
> 2010/8/26 Mariano Martinez Peck <marianopeck at gmail.com>:
> > - 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 was thinking that too. Apparently no encoding means that only 7bit
> characters should be used?
>
>
I am totally newbie with encoding. I have no idea about how many bits hahah.
The only thing I would like is that with "no encoding" I do what we were
doing until this change.



> > 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.
>
> This probably need some thinking. Because if one uses database through
> GLORP the encoding parameter should be passed somehow to lower levels.
>

Yes, I saw this after sending all the emails :(


> Would the ConnectionSettings in SqueakDBX level be right place?


ahhhh yes, I forgot about ConnectionSettings :)
That sounds more reasonable than Connection.
FOr all your changes and comments it seems you understood SqueakDBX quite
well and fast heheh


> And in
> Glorp I think the platform level seems to be good. Then in Glorp one
> could express
> (Login new)
>                database: (PostgreSQLPlatform withEncoding: #utf8);
>                username: 'yyyyy';
>                password: 'xxxx';
>                connectString: 'host' , '_' , 'database'
>
> (PostgreSQLPlatform withEncoding: #utf8) would be short cut for
> (PostgreSQLPlatform new encoding: #utf8).
>
>
> > maybe we can just set again the NullEncoder in that case?  or raise an
> error ?  what do you think?
>
> Yep, error checking code was not up to the task in the first try.
> Probably raise an error. Espesially if user has decided to use
> encoding (and data needs it). If
> code would continue silently with NullEncoder the data read would be
> corrupted.
>
>
I agree. Raise an error with a really clear message.
I would like to add tests for this encoding stuff, if it makes sense. I try
to keep tests updated and trying to cover most of the features.



>
> > Ok.... I run the benchmarks and I was rigth
>
> If I understood correctly berformance dropped over 10%. It is quite
> much. Have to see if that could be improved.
>

If you want, you can try it by yourself:

http://www.squeakdbx.org/Benchmarks

Easy, evaluate:*

DBXBenchmark* facility: *DBXPostgreFacility* facilityForBenchmark.

*DBXTinyBenchmarks* new runAll.




>
> > In addition, if someone has its own database using a particular encoding,
> and doesn't implement openConnection (that does the query, like you did in
> postgres) because he doesn't knwo, this
> > will be a problem beasue the database will have an encoding X and you
> will be encoding always with UTF8 ;)
>
> This is a problem. However I do feel that encoding should be checked
> when database is connected (at least when user has selected that
> encoding should be used).
>

yes, but only when the user has selected encoded


> Also endocoding should be property of the connection. If it would be
> class variable it would be impractical to connect to different
> databases with different encoding.
>
>
you are right, sorry about that.


> I think one possibility to takle these problems would be
> EncoderFactory user passes to the code. This factory would set encoder
> in connection


but weren't we going to put it in connectionSettings?


> based either on the database query
> or by preselected value. The query option would ask the connection
> about encoding (using message encodingName or something like that). If
> connection cant
> handle the message then exception is raised (user chosed to
> automatically select encoding in setting where code is not up to the
> task).
>
> The preselected option would just set right encoder to the connection.
> I think that validation of this choice should be skipped because it
> would render this option to be basically the same than the automatic
> option. Preselected encoding could be NullEncoder.
>
>
Uhh sorry, you lost me in this last paragraph. Maybe if I see the code I
understand better :


> If this sound sensible I will try to implement the changes in the
> weekend but cant promise I have the time. :)
>
>
That would be cool, but don't worry, no stress.
BTW...just by curious. where/why are you trying to use SqueakDBX?

cheers

mariano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeakdbx/attachments/20100827/2c71719d/attachment.htm