On Fri, Aug 27, 2010 at 8:10 AM, Panu Suominen panu.j.m.suominen@gmail.comwrote:
Thank you for excelent feedback.
thanks for your changes :)
2010/8/26 Mariano Martinez Peck marianopeck@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
2010/8/27 Mariano Martinez Peck marianopeck@gmail.com:
The only thing I would like is that with "no encoding" I do what we were doing until this change.
Ok. That will not be a problem.
but weren't we going to put it in connectionSettings? Uhh sorry, you lost me in this last paragraph. Maybe if I see the code I understand better
Yep. My explanation was not very clear. I write the code. Then it is easier to comment.
BTW...just by curious. where/why are you trying to use SqueakDBX?
I am working at the University of Jyväskylä (www.jyu.fi) in Finland and we have large legacy system that handles course registrations and such (korppi.jyu.fi). It is written in very rudimentary way on top of Tomcat, basically using plain jsp pages and servlets without any advanced framework. This approach makes some changes and improvements very hard to implement and too expensive. This problem is very big in the user interface level.
To improve our development speed we have investigated better approaches. Pharo+Seaside seems to be quite promising. Unfortunately we have to use our legacy database in the future implementation also. The database is run by postgresql and thus we need libraries to interact with it. I have tested PostgresV3 and it worked fine. However we are trying to find ORM approach and currently only working thing I have found is Glorp and it requires SqueakDBX.
On Fri, Aug 27, 2010 at 11:04 AM, Panu Suominen <panu.j.m.suominen@gmail.com
wrote:
2010/8/27 Mariano Martinez Peck marianopeck@gmail.com:
The only thing I would like is that with "no encoding" I do what we were doing until this change.
Ok. That will not be a problem.
but weren't we going to put it in connectionSettings? Uhh sorry, you lost me in this last paragraph. Maybe if I see the code I understand better
Yep. My explanation was not very clear. I write the code. Then it is easier to comment.
BTW...just by curious. where/why are you trying to use SqueakDBX?
I am working at the University of Jyväskylä (www.jyu.fi) in Finland and we have large legacy system that handles course registrations and such (korppi.jyu.fi). It is written in very rudimentary way on top of Tomcat, basically using plain jsp pages and servlets without any advanced framework. This approach makes some changes and improvements very hard to implement and too expensive. This problem is very big in the user interface level.
Ok, I understand. I hear that story several times ;)
To improve our development speed we have investigated better approaches. Pharo+Seaside seems to be quite promising.
Yes!
Unfortunately we have to use our legacy database in the future implementation also. The database is run by postgresql and thus we need libraries to interact with it. I have tested PostgresV3 and it worked fine. However we are trying to find ORM approach and currently only working thing I have found is Glorp and it requires SqueakDBX.
Wait....our biggest change to Glorp is that it now supports different database drivers. Before us, it has hardcoded to PostgresV2 driver. Now, you have an abstract class and a layer. And you are able to use the database driver you want. For the moment, we implemented 2 glorp drivers, one for SqueakDBX and one for PostgresV2. Thus, you can still use postgres native (smalltalk) driver instead of squeakdbx if you want.
Of course I still recommend using dbx as it is much faster and you have the same api for all databases. And you even did the worst part (install opendbx).
Anyway, if you want to load GLorp + native postgresv2 driver evaluate:
(ConfigurationOfGlorpDBX project version: '1.2') load: 'All with PostgreSQL native'
2010/8/27 Mariano Martinez Peck marianopeck@gmail.com:
Anyway, if you want to load GLorp + native postgresv2 driver evaluate:
(ConfigurationOfGlorpDBX project version: '1.2') load: 'All with PostgreSQL native'
Thanx for the tip. I am not sure if v2 works for postgresql 8.x.
On Fri, Aug 27, 2010 at 11:20 AM, Panu Suominen <panu.j.m.suominen@gmail.com
wrote:
2010/8/27 Mariano Martinez Peck marianopeck@gmail.com:
Anyway, if you want to load GLorp + native postgresv2 driver evaluate:
(ConfigurationOfGlorpDBX project version: '1.2') load: 'All with
PostgreSQL
native'
Thanx for the tip. I am not sure if v2 works for postgresql 8.x.
Ahhh I didn't know that...would be nice to know it. BTW, here is the history if you want:
http://www.squeakdbx.org/GLORP%20integration
Mariano
Panu Suominen wrote:
2010/8/27 Mariano Martinez Peck marianopeck@gmail.com:
Anyway, if you want to load GLorp + native postgresv2 driver evaluate:
(ConfigurationOfGlorpDBX project version: '1.2') load: 'All with PostgreSQL native'
Thanx for the tip. I am not sure if v2 works for postgresql 8.x.
I use V2 with postgres 8.X, and it works for me. During the connection setup, the postgres server can determine what protocol version should be used (V2 or V3). Unless the postgres developers decide that the V2 protocol should not be supported anymore (e.g. to trim the code base), there is no technical reason (IMHO) why the V2 protocol needs to be deprecated. And looking at the documentation for postgres 9.X beta, they make no mention of deprecating V2 support.
There is now native V3 support available, but I have not tried it yet. Just a few days ago, it was mentioned that it is in production use by its developers. Also mentioned was that the API (i.e. PG3Connection) is very similar to PGConnection, so making it work with GLORP should not be difficult. I hope to try at some point in the near future.
Of greater concern to me is the disconnect of Squeak/Pharo from the main line development of GLORP in VW Smalltalk. But that's a whole other discussion.
I made the changes I promised but they got erased because of creative use of mv. Apparently the work dir I have used have not existed for two weeks. Anyways I am writing those changes again. From the first implementation it seemed wise to link the encoding setting to Glorp login object and to DBXConnectionSettings. So I am still working on this one. :)
Of greater concern to me is the disconnect of Squeak/Pharo from the main line development of GLORP in VW Smalltalk. But that's a whole other discussion.
First, thaks for postgresql version info. Is there some place to read about that discussion or is the discussion yet to be made.
On Tue, Aug 31, 2010 at 9:14 PM, Panu Suominen panu.j.m.suominen@gmail.comwrote:
I made the changes I promised but they got erased because of creative use of mv. Apparently the work dir I have used have not existed for two weeks.
ufff :(
Anyways I am writing those changes again.
thanks for willing to do it
From the first implementation it seemed wise to link the encoding setting to Glorp login object and to DBXConnectionSettings. So I am still working on this one. :)
Uhhhh yes, I always forget about Glorp. This is a problem because Glorp shouldn't be aware of DBXConnectionSettings. Glorp should ONLY see the API of DatabaseDriver. This is the all idea, that you can easily change the database driver. If Glorp core uses DBXConnectionSettings, we are dead :(
I will try t think how to solve it too.
Of greater concern to me is the disconnect of Squeak/Pharo from the main line development of GLORP in VW Smalltalk. But that's a whole other discussion.
First, thaks for postgresql version info. Is there some place to read about that discussion or is the discussion yet to be made.
Glorp WAS and IS developed in VisualWorks Smalltalk (another Smalltalk dialect). Someone once port it to Squeak. The last squeak (and thus, Pharo) version of GLorp is like 2 o 3 years old. If you take the version of today of VisualWorks you will see mcuh more things and features in Glorp.
We once tried to port it, but it was very complicated and we didn't have too much time. We concentrated in fixing SqueakDatabaseAcceessor and being able to use ANY database driver. That's all our refactor and the thing behind the name GlorpDBX.
Cheers
Mariano
--
Panu _______________________________________________ SqueakDBX mailing list SqueakDBX@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/squeakdbx
I had very little time for this encoding issue last week. But it should be usable now. It need some polishing but I thought it would be better to get it out now than next week. I am not very familiar with monticello but I tried to package the codes. Hopefully it works.
Hi Panu. This is really cool. I have did a quick view and seems pretty good. I couldn't test it yet but I will do it and let you know. If everything is fine, I will commit it.
Cheers
Mariano
On Mon, Sep 6, 2010 at 2:36 AM, Panu Suominen panu.j.m.suominen@gmail.comwrote:
I had very little time for this encoding issue last week. But it should be usable now. It need some polishing but I thought it would be better to get it out now than next week. I am not very familiar with monticello but I tried to package the codes. Hopefully it works.
-- Panu
SqueakDBX mailing list SqueakDBX@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/squeakdbx
2010/9/6 Mariano Martinez Peck marianopeck@gmail.com:
Hi Panu. This is really cool. I have did a quick view and seems pretty good. I couldn't test it yet but I will do it and let you know. If everything is fine, I will commit it.
The package naming is not very good. And at least psencoding package does not depend on the packages it should. psencoding contains new methods to glorp and dbx classes. I think those changes should be split to some other package. However I am so new in the way of smalltalk that I don't know are these issues relevant in the long run...
2010/9/7 Panu Suominen panu.j.m.suominen@gmail.com:
2010/9/6 Mariano Martinez Peck marianopeck@gmail.com:
Hi Panu. This is really cool. I have did a quick view and seems pretty good. I couldn't test it yet but I will do it and let you know. If everything is fine, I will commit it.
The package naming is not very good. And at least psencoding package does not depend on the packages it should.
Ok. I think I got it right this time. encoding-changes.1.cs contains changes that were required to Glorp, SqueakDBX and such. They are done on the version 1.2 of GlorpDBX.
EncodingStrategy change set contains couple of classes that can be used to set how encoding should be determined. This change set is not required to make the GlorpDBX and friend work. It is only needed if one wants to control what encoding should be used.
Thanks Panu. I am looking at the code right now. I will give you my feedback. Thanks a lot :)
Two little questions...
1) If I DON'T want encoding, it says I don't need to do anything. It just doesn't encode because of the
^ encoder isNil ifTrue:[aString] ifFalse:[ encoder convertToSystemString: aString].
or the
^ encoder isNil ifTrue:[aByteArray ] ifFalse: [encoder convertFromSystemString: aByteArray].
I am right ? then....if we do that check with the nil...I don't need to set the Null encoder, isn't it ?
2) To set a particular encoding for SqueakDBX the way to do this is something like this:
connectionSettings := DBXConnectionSettings host: '127.0.0.1' port: '5432' database: 'sodbxtest' userName: 'sodbxtest' userPassword: 'sodbxtest' encodingStrategy: PSAutomaticEncoding new. "or any other encoder"
conn := DBXConnection platform: DBXPostgresPlatform new settings: connectionSettings. ......
is this correct?
And for Glorp it is something like:
login := Login new database: PostgreSQLPlatform new; username: 'sodbxtest'; password: 'sodbxtest'; connectString: '127.0.0.1_sodbxtest'; encodingStrategy: PSAutomaticEncoding new.
is this correct ?
3) How did you run both, SqueakDBX and GlorpDBX tests?
To squeakDBX did you modify DBXPostgreFacility >> createConnection and set there the encoder?
And for Glorp you changed DBXGlorpMainBackendTestPostgresql >> glorpBackendFacility ?
BTW....I will be en ESUG next week....will you be there?
Thanks!
mariano
On Fri, Sep 10, 2010 at 11:17 AM, Panu Suominen <panu.j.m.suominen@gmail.com
wrote:
2010/9/7 Panu Suominen panu.j.m.suominen@gmail.com:
2010/9/6 Mariano Martinez Peck marianopeck@gmail.com:
Hi Panu. This is really cool. I have did a quick view and seems pretty
good.
I couldn't test it yet but I will do it and let you know. If everything
is
fine, I will commit it.
The package naming is not very good. And at least psencoding package does not depend on the packages it should.
Ok. I think I got it right this time. encoding-changes.1.cs contains changes that were required to Glorp, SqueakDBX and such. They are done on the version 1.2 of GlorpDBX.
EncodingStrategy change set contains couple of classes that can be used to set how encoding should be determined. This change set is not required to make the GlorpDBX and friend work. It is only needed if one wants to control what encoding should be used.
-- Panu
Few more things:
1) PSAutomaticEncoding >> encoderFor: anObject | encoding | encoding := anObject queryEncoding. ^TextConverter newForEncoding: encoding.
I think it would be better to be:
PSAutomaticEncoding >> encoderFor: aConnection | encoding | encoding := aConnection queryEncoding. ^TextConverter newForEncoding: encoding.
Since object DNU queryEncodying, but DBXConnection.
2) testUTF8IsDetected fails because there is no implementor of runScenario
3) TO integrate it, I was thnking I can put the classes of 'EncodingStrategy' into a new 'OpenDBX-Core-Encoding' And the tests in 'OpenDBX-Core-Tests-Encoding'
In addition, I have to rename PSAclassName to DBXAclassName. Do you agree with this?
cheers
mariano
On Sat, Sep 11, 2010 at 5:49 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Thanks Panu. I am looking at the code right now. I will give you my feedback. Thanks a lot :)
Two little questions...
- If I DON'T want encoding, it says I don't need to do anything. It just
doesn't encode because of the
^ encoder isNil ifTrue:[aString] ifFalse:[ encoderconvertToSystemString: aString].
or the
^ encoder isNil ifTrue:[aByteArray ] ifFalse: [encoderconvertFromSystemString: aByteArray].
I am right ? then....if we do that check with the nil...I don't need to set the Null encoder, isn't it ?
- To set a particular encoding for SqueakDBX the way to do this is
something like this:
connectionSettings := DBXConnectionSettings host: '127.0.0.1' port: '5432' database: 'sodbxtest' userName: 'sodbxtest' userPassword: 'sodbxtest' encodingStrategy: PSAutomaticEncoding new. "or any otherencoder"
conn := DBXConnection platform: DBXPostgresPlatform new settings:connectionSettings. ......
is this correct?
And for Glorp it is something like:
login := Login new database: PostgreSQLPlatform new; username: 'sodbxtest'; password: 'sodbxtest'; connectString: '127.0.0.1_sodbxtest'; encodingStrategy: PSAutomaticEncoding new.is this correct ?
- How did you run both, SqueakDBX and GlorpDBX tests?
To squeakDBX did you modify DBXPostgreFacility >> createConnection and set there the encoder?
And for Glorp you changed DBXGlorpMainBackendTestPostgresql >> glorpBackendFacility ?
BTW....I will be en ESUG next week....will you be there?
Thanks!
mariano
On Fri, Sep 10, 2010 at 11:17 AM, Panu Suominen < panu.j.m.suominen@gmail.com> wrote:
2010/9/7 Panu Suominen panu.j.m.suominen@gmail.com:
2010/9/6 Mariano Martinez Peck marianopeck@gmail.com:
Hi Panu. This is really cool. I have did a quick view and seems pretty
good.
I couldn't test it yet but I will do it and let you know. If everything
is
fine, I will commit it.
The package naming is not very good. And at least psencoding package does not depend on the packages it should.
Ok. I think I got it right this time. encoding-changes.1.cs contains changes that were required to Glorp, SqueakDBX and such. They are done on the version 1.2 of GlorpDBX.
EncodingStrategy change set contains couple of classes that can be used to set how encoding should be determined. This change set is not required to make the GlorpDBX and friend work. It is only needed if one wants to control what encoding should be used.
-- Panu
2010/9/11 Mariano Martinez Peck marianopeck@gmail.com:
Few more things:
1) PSAutomaticEncoding >> encoderFor: anObject I think it would be better to be: PSAutomaticEncoding >> encoderFor: aConnection Since object DNU queryEncodying, but DBXConnection.
You are right. I thought that same kind of encoding strategy scheme could be used to some other things as well. But anObject is too general name.
2) testUTF8IsDetected fails because there is no implementor of runScenario
It needs mocketry to run. I though that I would add some kind of notice about this requirement when class is initialized or something, but I runned out of time to find out how to do this proprely.
Other option is that I take extra effort to write the test without mocketry. Is that better option?
3) TO integrate it, I was thnking I can put the classes of 'EncodingStrategy' into a new 'OpenDBX-Core-Encoding' And the tests in 'OpenDBX-Core-Tests-Encoding' In addition, I have to rename PSAclassName to DBXAclassName. Do you agree with this?
Sounds good. I think my changes are so small that licensing them sounds funny but because there have been some licensing issues it might be better that I clearly state that my changes are done under MIT license.
If I remember correctly Glorp uses LGPL? If so then the change to Login class has to be LGPL too.
On Sat, Sep 11, 2010 at 7:07 PM, Panu Suominen panu.j.m.suominen@gmail.comwrote:
2010/9/11 Mariano Martinez Peck marianopeck@gmail.com:
Few more things:
- PSAutomaticEncoding >> encoderFor: anObject
I think it would be better to be: PSAutomaticEncoding >> encoderFor: aConnection Since object DNU queryEncodying, but DBXConnection.
You are right. I thought that same kind of encoding strategy scheme could be used to some other things as well. But anObject is too general name.
Yes, I imagined it was because of that....but it cannot be too general, since it has to understand queryEncodying....
- testUTF8IsDetected fails because there is no implementor of
runScenario
It needs mocketry to run. I though that I would add some kind of notice about this requirement when class is initialized or something, but I runned out of time to find out how to do this proprely.
Other option is that I take extra effort to write the test without mocketry. Is that better option?
Yes, please. If that's the only place where it is used then yes. Because depending on other packages is complicated. You never know if there is someone who maintains it. And I want to to always run fine in Pharo. Pharo changes a lot. So yes....since it seems mockery is only used there, I would try to avoid the dependecy.
- TO integrate it, I was thnking I can put the classes of
'EncodingStrategy' into a new 'OpenDBX-Core-Encoding' And the tests in 'OpenDBX-Core-Tests-Encoding' In addition, I have to rename PSAclassName to DBXAclassName. Do you agree with this?
Sounds good. I think my changes are so small that licensing them sounds funny but because there have been some licensing issues it might be better that I clearly state that my changes are done under MIT license.
Excellent, because I was just going to ask you that :) Thanks for doing it mit.
If I remember correctly Glorp uses LGPL? If so then the change to Login class has to be LGPL too.
yes...I guess.
Thanks Panu.
2010/9/11 Mariano Martinez Peck marianopeck@gmail.com:
Other option is that I take extra effort to write the test without mocketry. Is that better option?
Yes, please.
Ok. It is not big change. I try to do it next week.
Thanks Panu.
That was not such a big deal. I owe for the people who made the Glorp and other tools involved in this. So thanks to you too. :)
Mariano Martinez Peck wrote:
On Sat, Sep 11, 2010 at 7:07 PM, Panu Suominen
If I remember correctly Glorp uses LGPL? If so then the change to Login class has to be LGPL too.yes...I guess.
Thanks Panu.
No. You can dual license your changes - both LGPL and MIT. If, by some miracle, Glorp is re-licensed as MIT, then there won't be a residual problem with your code being LGPL.
On Sun, Sep 12, 2010 at 8:16 AM, Yanni Chiu yanni@rogers.com wrote:
Mariano Martinez Peck wrote:
On Sat, Sep 11, 2010 at 7:07 PM, Panu Suominen If I remember correctly Glorp uses LGPL? If so then the change to Login class has to be LGPL too.
yes...I guess.
Thanks Panu.
No. You can dual license your changes - both LGPL and MIT. If, by some miracle, Glorp is re-licensed as MIT, then there won't be a residual problem with your code being LGPL.
I talked with Alan Night at ESUG and we was thinking to release Glorp as MIT. I really rellay tried to make him do that...he is still traveling right now. But hopefully in few weeks he does something about it :)
SqueakDBX mailing list SqueakDBX@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/squeakdbx
2010/9/11 Mariano Martinez Peck marianopeck@gmail.com:
Thanks Panu. I am looking at the code right now. I will give you my feedback. Thanks a lot :)
Two little questions...
- If I DON'T want encoding, it says I don't need to do anything. It just
doesn't encode because of the
^ encoder isNil ifTrue:[aString] ifFalse:[ encoder convertToSystemString: aString].
or the
^ encoder isNil ifTrue:[aByteArray ] ifFalse: [encoder convertFromSystemString: aByteArray].
I am right ? then....if we do that check with the nil...I don't need to set the Null encoder, isn't it ?
That is right. At first I thought using NullEncodingStrategy to handle that case would be wise. However when I cleaned the packaging to two separate "patches", original solution did not work. So, basically NullEncodingStrategy is not needed. It can be used to emphasize fact that system is using internal string format.
2) To set a particular encoding for SqueakDBX the way to do this is something like this: is this correct?
That is how it should work. If I did not break anything when altering package structure..
And for Glorp it is something like: is this correct ?
Yes.
- How did you run both, SqueakDBX and GlorpDBX tests?
To squeakDBX did you modify DBXPostgreFacility >> createConnection and set there the encoder? And for Glorp you changed DBXGlorpMainBackendTestPostgresql >> glorpBackendFacility ?
In my development environment I did not succeeded to run SqueakDBX test with green bar without any modifications. It seemed that it would have needed extra effort to first hunt down those problems and then add test to then encoding stuff. I haven't had that time yet. Hopefully I will have next week.
BTW....I will be en ESUG next week....will you be there?
Unfortunately no. Maybe next year if we start using smalltalk at my work... ;)
Ok....finally today I had some time and I integrate all changes and updated the Metacello configurations. I would really appreaciate if you could take a look and let me know if you find it good also. I run the tests with and without encoding and seems to work.
I didn't integrate testUTF8IsDetected since it depends in mocks...if you then come up with a new version just let me know.
To install SqueakDBX only:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSqueakDBX'; load.
and then (ConfigurationOfSqueakDBX project version: '1.3') load.
And for GlorpDBX+SqueakDBX:
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGlorpDBX'; load.
and then (ConfigurationOfGlorpDBX project version: '1.3') load.
Thanks
Mariano
On Sat, Sep 11, 2010 at 5:49 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Thanks Panu. I am looking at the code right now. I will give you my feedback. Thanks a lot :)
Two little questions...
- If I DON'T want encoding, it says I don't need to do anything. It just
doesn't encode because of the
^ encoder isNil ifTrue:[aString] ifFalse:[ encoderconvertToSystemString: aString].
or the
^ encoder isNil ifTrue:[aByteArray ] ifFalse: [encoderconvertFromSystemString: aByteArray].
I am right ? then....if we do that check with the nil...I don't need to set the Null encoder, isn't it ?
- To set a particular encoding for SqueakDBX the way to do this is
something like this:
connectionSettings := DBXConnectionSettings host: '127.0.0.1' port: '5432' database: 'sodbxtest' userName: 'sodbxtest' userPassword: 'sodbxtest' encodingStrategy: PSAutomaticEncoding new. "or any otherencoder"
conn := DBXConnection platform: DBXPostgresPlatform new settings:connectionSettings. ......
is this correct?
And for Glorp it is something like:
login := Login new database: PostgreSQLPlatform new; username: 'sodbxtest'; password: 'sodbxtest'; connectString: '127.0.0.1_sodbxtest'; encodingStrategy: PSAutomaticEncoding new.is this correct ?
- How did you run both, SqueakDBX and GlorpDBX tests?
To squeakDBX did you modify DBXPostgreFacility >> createConnection and set there the encoder?
And for Glorp you changed DBXGlorpMainBackendTestPostgresql >> glorpBackendFacility ?
BTW....I will be en ESUG next week....will you be there?
Thanks!
mariano
On Fri, Sep 10, 2010 at 11:17 AM, Panu Suominen < panu.j.m.suominen@gmail.com> wrote:
2010/9/7 Panu Suominen panu.j.m.suominen@gmail.com:
2010/9/6 Mariano Martinez Peck marianopeck@gmail.com:
Hi Panu. This is really cool. I have did a quick view and seems pretty
good.
I couldn't test it yet but I will do it and let you know. If everything
is
fine, I will commit it.
The package naming is not very good. And at least psencoding package does not depend on the packages it should.
Ok. I think I got it right this time. encoding-changes.1.cs contains changes that were required to Glorp, SqueakDBX and such. They are done on the version 1.2 of GlorpDBX.
EncodingStrategy change set contains couple of classes that can be used to set how encoding should be determined. This change set is not required to make the GlorpDBX and friend work. It is only needed if one wants to control what encoding should be used.
-- Panu
2010/9/25 Mariano Martinez Peck marianopeck@gmail.com:
Ok....finally today I had some time and I integrate all changes and updated the Metacello configurations. I would really appreaciate if you could take a look and let me know if you find it good also. I run the tests with and without encoding and seems to work.
Thanx. I try to check them when I have time.
I didn't integrate testUTF8IsDetected since it depends in mocks...if you then come up with a new version just let me know.
Actually I was just making those changes. Changed test is attached. Those changes are made on top of the last change set. I can make the same changes to your codes if that is better.
On Sat, Sep 25, 2010 at 8:37 PM, Panu Suominen panu.j.m.suominen@gmail.comwrote:
2010/9/25 Mariano Martinez Peck marianopeck@gmail.com:
Ok....finally today I had some time and I integrate all changes and
updated
the Metacello configurations. I would really appreaciate if you could
take
a look and let me know if you find it good also. I run the tests with and without encoding and seems to work.
Thanx. I try to check them when I have time.
I didn't integrate testUTF8IsDetected since it depends in mocks...if you then come up with a new version just let me know.
Actually I was just making those changes. Changed test is attached. Those changes are made on top of the last change set. I can make the same changes to your codes if that is better.
Excellent. In
Name: OpenDBX-Core-Mariano.274 Author: Mariano Time: 25 September 2010, 9:01:32 pm UUID: ff5d0f0c-9fe2-493a-9245-f7a0608994cb Ancestors: OpenDBX-Core-MarianoMartinezPeck.273
Added testUTF8IsDetected
-- Panu
2010/9/25 Panu Suominen panu.j.m.suominen@gmail.com:
2010/9/25 Mariano Martinez Peck marianopeck@gmail.com:
Ok....finally today I had some time and I integrate all changes and updated the Metacello configurations. I would really appreaciate if you could take a look and let me know if you find it good also. I run the tests with and without encoding and seems to work.
Thanx. I try to check them when I have time.
Sorry that it took so long. Hopefully I can start answer more faster because we are going to the direction using smalltalk more and more now.
Version 1.3 ConfigurationOfGlorpDBX in squeaksources Metacello Repository did not contain changes that pass the encoding strategy down from Glorp Login to DBXConnectionSettings. I created new version to SqueakDBX project (in squeacksource) (GlorpDriverSqueakDBX-PanuSuominen.9) which fixed this problem. However I found out that you had already fixed that in GlorpDriverSqueakDBX-MarianoMartinezPeck.9. So it might be best if the version I created would be removed. Otherwise it seems to work ok. Would it be ok to update 1.3 to contain the version you created?
DatabasePlatform of Glorp seems to contain characterEncoding but I have not yet found out how this is used. It does not seem to solve the same problem. Does anyone know about it?
On Fri, Oct 22, 2010 at 11:49 AM, Panu Suominen <panu.j.m.suominen@gmail.com
wrote:
2010/9/25 Panu Suominen panu.j.m.suominen@gmail.com:
2010/9/25 Mariano Martinez Peck marianopeck@gmail.com:
Ok....finally today I had some time and I integrate all changes and
updated
the Metacello configurations. I would really appreaciate if you could
take
a look and let me know if you find it good also. I run the tests with
and
without encoding and seems to work.
Thanx. I try to check them when I have time.
Sorry that it took so long. Hopefully I can start answer more faster because we are going to the direction using smalltalk more and more now.
Excellent! that's good news.
Version 1.3 ConfigurationOfGlorpDBX in squeaksources Metacello Repository did not contain changes that pass the encoding strategy down from Glorp Login to DBXConnectionSettings. I created new version to SqueakDBX project (in squeacksource) (GlorpDriverSqueakDBX-PanuSuominen.9) which fixed this problem. However I found out that you had already fixed that in GlorpDriverSqueakDBX-MarianoMartinezPeck.9. So it might be best if the version I created would be removed. Otherwise it seems to work ok. Would it be ok to update 1.3 to contain the version you created?
Done.
Just for you to know it, the idea of Metacello is to tag mostly releases. Maitaining a metacello version for every Monticello commit, doesn't make sense ;) But...there is a way to load all the latest code, which is loading a baseline.
(ConfgurationOfGlorpDBX project version: '1.2-baseline') load.
In the future, Metacello will provide something much easier for this also. But this is what we have for the moment. In metacello faq it says:
http://code.google.com/p/metacello/wiki/FAQ#How_do_I_load_the_last_version_o... ?
DatabasePlatform of Glorp seems to contain characterEncoding but I have not yet found out how this is used. It does not seem to solve the same problem. Does anyone know about it?
I have no idea. But for these things of really Glorp, you may want to copy also the official Glorp mailing list: , glorp-group@googlegroups.com,
Thanks
Mariano
-- Panu
squeakdbx@lists.squeakfoundation.org
-
Mariano Martinez Peck -
Panu Suominen -
Yanni Chiu