<br><br><div class="gmail_quote">On Wed, Aug 25, 2010 at 7:20 AM, Panu Suominen <span dir="ltr"><<a href="mailto:panu.j.m.suominen@gmail.com">panu.j.m.suominen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2010/8/24 Mariano Martinez Peck <<a href="mailto:marianopeck@gmail.com">marianopeck@gmail.com</a>>:<br>
<div class="im"><br>
> Yes. So that I can see it. Do you know if it breaks compatibility with other<br>
> databases or OS? because SqueakDBX classes like DBXConnection should be<br>
> cross-backend.<br>
<br>
</div>I don't know how cross-platform my fix is. Database part should be<br>
fine. Postgresql can now detect the encoding.<br></blockquote><div><br>Thanks a lot for the changeset. Now I will test with different OS and databases and I will let you know. <br> <br>now a couple of questions:<br><br>- 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 set in: <br>
<br>DBXConnection >> initialize<br><br>instead of TextConverter newForEncoding: #utf8.<br><br>Then, for postgres, you will be using the one from TextConverter newForEncoding: (r rows first valueAt: 1).<br><br>Even more, I would like to make it optional. Maybe we can create DBXCOnnection class >> platform: aPlatform settings: aConnectionSettings encode: anEncoder<br>
and that will do:<br><br>platform: aPlatform settings: aConnectionSettings encoder: anEncoder<br> ^self new<br> platform: aPlatform;<br> settings: aConnectionSettings;<br> encoder: anEncoder;<br> yourself<br>
<br>Finally, the cleint code (your app code) creates the connection with that message :)<br><br>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.<br>
<br>- What happens is the database supports and specific encoding that Pharo doesn't support?<br> TextConverter newForEncoding: (r rows first valueAt: 1).<br><br>will return nil, causing UndefinedObject dnu something.<br>
<br>maybe we can just set again the NullEncoder in that case? or raise an error ? what do you think?<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Others database platforms just don't know anything about encoding<br>
(they use default utf-8). If other smalltalk dialects have<br>
TextConverter then it should be fine.<br>
If they haven't then I can implement another abstraction layer to<br>
provide compatibility between dialects.<br>
<div class="im"><br>
> If you want to can use another new package with your commit.<br>
</div>I am sorry, but I did not quite understand what you meant...<br>
<br>
Unfortunately I am a little busy at work right now so I did not had<br>
time to learn how to use monticello properly to create version only<br>
containing required changes.<br>
For this reason I attached change set file to this mail.<br></blockquote><div><br>Don't worry :) <br><br>thanks!<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
>> Also is there a connection pooling facility for SqueakDBX or Glorp?<br>
> Yes, several.<br>
</div>Thank you.<br>
<br>
--<br>
<font color="#888888">Panu<br>
</font></blockquote></div><br>