Mariano, I had to change PGConnection class>>#timestampWithTimezoneConverter otherwise it wouldn't want to parse my timestamp with time zone colums that look like '2010-06-16 00:01:00+02' (no millis to skip, no minutes in the offset). Now, my fix is a bit dirty, because it assumes that what I see on my system is the rule while it probably isn't. timestampWithTimezoneConverter ^[ :s | | direction offset | direction := (s at: 20) = $- ifTrue: [ -1 ] ifFalse: [ 1 ]. offset := Duration hours: (s copyFrom: 21 to: 22) asInteger * direction. DateAndTime year: (s copyFrom: 1 to: 4) asInteger month: (s copyFrom: 6 to: 7) asInteger day: (s copyFrom: 9 to: 10) asInteger hour: (s copyFrom: 12 to: 13) asInteger minute: (s copyFrom: 15 to: 16) asInteger second: (s copyFrom: 18 to: 19) asInteger offset: offset ] I can definitively write a better version that handles different kinds of formats in a flexible way. I also think the #copyFrom:to:'s are waistful and could at least be replaced with ReadStream>>#on:from:to:'s. This goes for some other converters as well. This code is execute for each column so seems resource critical. This change did not come up as a failed unit test, so maybe I should also try to add one ? On my Pharo 1.0 image, all PGConnection tests pass. Of the 844 GlorpTest tests, 2 fail: GlorpRowMapForMementosCollectionTest>>#testRBSmallDictionary and GlorpSelectCommandTest>>#testExecute. GlorpTest-DBTests all succeed. GlorpMainBackendTest fails. I also had to add NativePostgresDriver>>#externalDatabaseErrorSignal externalDatabaseErrorSignal ^Dialect error This also came up during day to day usage and not as a test failure. So, for Glorp itself there were no real problems ;-) Maybe just one feature request: on VW NC 7.7 Glorp (when you enable logging) prints timing info on all queries, on Pharo only for updates and deletes, which is strange. Sven On 11 Jun 2010, at 00:32, Mariano Martinez Peck wrote:
On Thu, Jun 10, 2010 at 9:07 PM, Sven Van Caekenberghe <sven@beta9.be> wrote: Mariano,
The fact that you did the port is more than official enough for me ;-)
First, thanks a lot for the port, I know that this must be a lot of work.
I think that Glorp and the different drivers are _very_ important for many people: talking to an RDBMS is an absolute requirement in almost any serious application. Without it, Pharo/Seaside becomes almost unusable in most commercial contexts. Only in some specific cases the other persistency strategies would be applicable.
Thanks. This is exactly why we did SqueakDBX ;) and then GlorpDBX.
I would very much like to help in making the Glorp+PostgreSQL combination easy to use in Pharo. Writing a ConfigurationOf.. is a bit to much for me right now though.
Great. So, at least, we should make it work, then we see how to load it.
Concerning my changes, I can send them to you, or save modified versions of the packages where you want. BTW, I was working on Pharo 1.0
mmmmm I thought Glorp was already working in 1.0. Weird...which are the changes? yes, please send me your changes. We have committed Glorp packages in SqueakDBX repository as we have been changing a lot of things. A big refactor to Glorp in order to support multiple database drivers.
You can send me the changes or commit them to the packages that are in SqueakDBX repository at least. I am not sure in Glorp original repository, but at least in SqueakDBX repository for sure: http://www.squeaksource.com/SqueakDBX
Please, run all the tests before comitting.
Cheers
Mariano
Should we continue this discussion over the mailing list or privately ?
Sven
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users