On Fri, Aug 27, 2010 at 8:10 AM, Panu Suominen
> 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
> > that the transformation brings some overhead in the query result
> > 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
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:
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
> 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?