SqueakDBX October 2010

squeakdbx@lists.squeakfoundation.org

2 participants
1 discussions

Re: [SqueakDBX] Character encoding and pooling in SqueakDBX and Glorp
by Mariano Martinez Peck 22 Oct '10

22 Oct '10

On Fri, Aug 27, 2010 at 8:10 AM, Panu Suominen <panu.j.m.suominen(a)gmail.com>wrote: > Thank you for excelent feedback. > thanks for your changes :) > > 2010/8/26 Mariano Martinez Peck <marianopeck(a)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

3 24

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SqueakDBX October 2010