Re: [Pharo-dev] Prepared Statements on PostgresV2?
Stef wrote:
Now I do not get it. Did you port it to Pharo?
I spend about a day evaluating it in 40272. I looked at three packages (and their two test packages). PostgresV3-Core handles the V3 protocol, makes a connection using a socket, provides a result set with rows, columns and text converters. I got a few problems in the unit tests, looks like something in the way floats are handled is different (PG3SocketReadStream>>parseFloatLength: and there is a method missing PG3SocketReadStream>>parseScaledDecimal PostgresV3-Pool provides a connection pool. I was able to use that to connect to a database, execute queries and get data out of it. Issues there are trivial: PG3Connection>>md5HashMessage: aString ^Smalltalk globals at: #MD5 ifPresent: [ :md5 | (md5 hashMessage: aString) hex asLowercase ] ifAbsent: [ WebUtils md5Digest: aString ] We don't have WebUtils, but we have MD5 Then there is PostgresV3-CodeMirror. In PG3SchemaMirror there are some overrides to select a different compiler (+parser) and code highlighter. That allows subclasses to have plsql functions as methods, using the PG3FunctionMirror. In Pharo, I couldn't easily find how to change the code highlighter in Nautilus. The PG3Compiler just changes the parser used to PG3Parser. The PG3Parser is a subclass from the squeak parser and so uses some things that work a bit different PG3Parser>>checkSyntaxFor: uses a cue instance variable. It is not a full plsql parser, relying on the database to check syntax. PG3SchemaChanges uses Toolbuilder to show a window with the differences between the functions in the database and those in the image and select which ones to change. Stephan
thanks for the report. Stef Le 11/1/15 00:29, Stephan Eggermont a écrit :
Stef wrote:
Now I do not get it. Did you port it to Pharo?
I spend about a day evaluating it in 40272. I looked at three packages (and their two test packages).
PostgresV3-Core handles the V3 protocol, makes a connection using a socket, provides a result set with rows, columns and text converters.
I got a few problems in the unit tests, looks like something in the way floats are handled is different (PG3SocketReadStream>>parseFloatLength: and there is a method missing PG3SocketReadStream>>parseScaledDecimal
PostgresV3-Pool provides a connection pool.
I was able to use that to connect to a database, execute queries and get data out of it. Issues there are trivial:
PG3Connection>>md5HashMessage: aString
^Smalltalk globals at: #MD5 ifPresent: [ :md5 | (md5 hashMessage: aString) hex asLowercase ] ifAbsent: [ WebUtils md5Digest: aString ]
We don't have WebUtils, but we have MD5
Then there is PostgresV3-CodeMirror.
In PG3SchemaMirror there are some overrides to select a different compiler (+parser) and code highlighter. That allows subclasses to have plsql functions as methods, using the PG3FunctionMirror.
In Pharo, I couldn't easily find how to change the code highlighter in Nautilus.
The PG3Compiler just changes the parser used to PG3Parser. The PG3Parser is a subclass from the squeak parser and so uses some things that work a bit different PG3Parser>>checkSyntaxFor: uses a cue instance variable. It is not a full plsql parser, relying on the database to check syntax.
PG3SchemaChanges uses Toolbuilder to show a window with the differences between the functions in the database and those in the image and select which ones to change.
Stephan
Developping the database protocols in Pharo is simply the best solution because Pharo is a cross-plateforms solution and it's necessary to have cross-plateforms frameworks for it. This solution will facilitate the deploiement of Pharo solutions because no configuration must be doing on the hosts. The Pharo image must be simply be copied. But yes it's a big work and I think that the priorities must be done on some databases servers as MySQL, Postgresql and SQLite. In the open source world, the protocols are more accessibles and the communities can help us. Olivier ;-) 2015-01-11 12:16 GMT+01:00 stepharo <stepharo@free.fr>:
thanks for the report.
Stef
Le 11/1/15 00:29, Stephan Eggermont a écrit :
Stef wrote:
Now I do not get it. Did you port it to Pharo?
I spend about a day evaluating it in 40272. I looked at three packages (and their two test packages).
PostgresV3-Core handles the V3 protocol, makes a connection using a socket, provides a result set with rows, columns and text converters.
I got a few problems in the unit tests, looks like something in the way floats are handled is different (PG3SocketReadStream>>parseFloatLength: and there is a method missing PG3SocketReadStream>>parseScaledDecimal
PostgresV3-Pool provides a connection pool.
I was able to use that to connect to a database, execute queries and get data out of it. Issues there are trivial:
PG3Connection>>md5HashMessage: aString
^Smalltalk globals at: #MD5 ifPresent: [ :md5 | (md5 hashMessage: aString) hex asLowercase ] ifAbsent: [ WebUtils md5Digest: aString ]
We don't have WebUtils, but we have MD5
Then there is PostgresV3-CodeMirror.
In PG3SchemaMirror there are some overrides to select a different compiler (+parser) and code highlighter. That allows subclasses to have plsql functions as methods, using the PG3FunctionMirror.
In Pharo, I couldn't easily find how to change the code highlighter in Nautilus.
The PG3Compiler just changes the parser used to PG3Parser. The PG3Parser is a subclass from the squeak parser and so uses some things that work a bit different PG3Parser>>checkSyntaxFor: uses a cue instance variable. It is not a full plsql parser, relying on the database to check syntax.
PG3SchemaChanges uses Toolbuilder to show a window with the differences between the functions in the database and those in the image and select which ones to change.
Stephan
Hi Olivier, Native driver in Pharo is good news :) Lack of Sql server support is bad news (I invested a lot in it for a long time, and I'm a fan) but I'll go for postgresql, I think I should like it too, I created a table once and did a select with it (haha) Regards, Alain Le 11/01/2015 12:20, olivier auverlot a écrit :
Developping the database protocols in Pharo is simply the best solution because Pharo is a cross-plateforms solution and it's necessary to have cross-plateforms frameworks for it. This solution will facilitate the deploiement of Pharo solutions because no configuration must be doing on the hosts. The Pharo image must be simply be copied.
But yes it's a big work and I think that the priorities must be done on some databases servers as MySQL, Postgresql and SQLite. In the open source world, the protocols are more accessibles and the communities can help us.
Olivier ;-)
2015-01-11 12:16 GMT+01:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
thanks for the report.
Stef
Le 11/1/15 00:29, Stephan Eggermont a écrit :
Stef wrote: >Now I do not get it. > Did you port it to Pharo?
I spend about a day evaluating it in 40272. I looked at three packages (and their two test packages).
PostgresV3-Core handles the V3 protocol, makes a connection using a socket, provides a result set with rows, columns and text converters.
I got a few problems in the unit tests, looks like something in the way floats are handled is different (PG3SocketReadStream>>parseFloatLength: and there is a method missing PG3SocketReadStream>>parseScaledDecimal
PostgresV3-Pool provides a connection pool.
I was able to use that to connect to a database, execute queries and get data out of it. Issues there are trivial:
PG3Connection>>md5HashMessage: aString
^Smalltalk globals at: #MD5 ifPresent: [ :md5 | (md5 hashMessage: aString) hex asLowercase ] ifAbsent: [ WebUtils md5Digest: aString ]
We don't have WebUtils, but we have MD5
Then there is PostgresV3-CodeMirror.
In PG3SchemaMirror there are some overrides to select a different compiler (+parser) and code highlighter. That allows subclasses to have plsql functions as methods, using the PG3FunctionMirror.
In Pharo, I couldn't easily find how to change the code highlighter in Nautilus.
The PG3Compiler just changes the parser used to PG3Parser. The PG3Parser is a subclass from the squeak parser and so uses some things that work a bit different PG3Parser>>checkSyntaxFor: uses a cue instance variable. It is not a full plsql parser, relying on the database to check syntax.
PG3SchemaChanges uses Toolbuilder to show a window with the differences between the functions in the database and those in the image and select which ones to change.
Stephan
Supporting open source database is the first step but you're right, we must also propose a solution for proprietary databases. The difficulty is to create an framework that proposes the ability to mix native driver (as level 4 in JDBC) and driver wrappers for undocumented protocols. As you, I'm a big fan of MSQL Server but keeps secret this information ;-) Olivier 2015-01-11 13:00 GMT+01:00 Alain Rastoul <alf.mmm.cat@gmail.com>:
Hi Olivier,
Native driver in Pharo is good news :)
Lack of Sql server support is bad news (I invested a lot in it for a long time, and I'm a fan) but I'll go for postgresql, I think I should like it too, I created a table once and did a select with it (haha)
Regards,
Alain
Le 11/01/2015 12:20, olivier auverlot a écrit :
Developping the database protocols in Pharo is simply the best solution because Pharo is a cross-plateforms solution and it's necessary to have cross-plateforms frameworks for it. This solution will facilitate the deploiement of Pharo solutions because no configuration must be doing on the hosts. The Pharo image must be simply be copied.
But yes it's a big work and I think that the priorities must be done on some databases servers as MySQL, Postgresql and SQLite. In the open source world, the protocols are more accessibles and the communities can help us.
Olivier ;-)
2015-01-11 12:16 GMT+01:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
thanks for the report.
Stef
Le 11/1/15 00:29, Stephan Eggermont a écrit :
Stef wrote: >Now I do not get it. > Did you port it to Pharo?
I spend about a day evaluating it in 40272. I looked at three packages (and their two test packages).
PostgresV3-Core handles the V3 protocol, makes a connection using a socket, provides a result set with rows, columns and text converters.
I got a few problems in the unit tests, looks like something in the way floats are handled is different (PG3SocketReadStream>>parseFloatLength: and there is a method missing PG3SocketReadStream>> parseScaledDecimal
PostgresV3-Pool provides a connection pool.
I was able to use that to connect to a database, execute queries and get data out of it. Issues there are trivial:
PG3Connection>>md5HashMessage: aString
^Smalltalk globals at: #MD5 ifPresent: [ :md5 | (md5 hashMessage: aString) hex asLowercase ] ifAbsent: [ WebUtils md5Digest: aString ]
We don't have WebUtils, but we have MD5
Then there is PostgresV3-CodeMirror.
In PG3SchemaMirror there are some overrides to select a different compiler (+parser) and code highlighter. That allows subclasses to have plsql functions as methods, using the PG3FunctionMirror.
In Pharo, I couldn't easily find how to change the code highlighter in Nautilus.
The PG3Compiler just changes the parser used to PG3Parser. The PG3Parser is a subclass from the squeak parser and so uses some things that work a bit different PG3Parser>>checkSyntaxFor: uses a cue instance variable. It is not a full plsql parser, relying on the database to check syntax.
PG3SchemaChanges uses Toolbuilder to show a window with the differences between the functions in the database and those in the image and select which ones to change.
Stephan
Le 11/01/2015 14:03, olivier auverlot a écrit :
Supporting open source database is the first step but you're right, we must also propose a solution for proprietary databases. The difficulty is to create an framework that proposes the ability to mix native driver (as level 4 in JDBC) and driver wrappers for undocumented protocols. Seeing how fast MS is trying to change, perhaps wait a while and see how it comes (and may be they will open source Sql, I don't think but who knows). One could also look at the source code of the free jtds driver (it works very well) as a reference implementation and at the free tds docs.
About Postgresql, I was joking at my very bad knowledge, but for the few I saw in docs, it seems to be a nice beast. Sqlite and Postgresql are good choices IMHO, Mysql not sure but as there is already a smalltalk native driver IIRC, it may be not too difficult (and it seems to be fairly used too).
As you, I'm a big fan of MSQL Server but keeps secret this information ;-)
Don't worry, I'll keep your secret secret :)
Olivier
-- Regards, Alain
On Sun, Jan 11, 2015 at 6:41 PM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:
Le 11/01/2015 14:03, olivier auverlot a écrit :
Supporting open source database is the first step but you're right, we must also propose a solution for proprietary databases. The difficulty is to create an framework that proposes the ability to mix native driver (as level 4 in JDBC) and driver wrappers for undocumented protocols.
Seeing how fast MS is trying to change, perhaps wait a while and see how it comes (and may be they will open source Sql, I don't think but who knows). One could also look at the source code of the free jtds driver (it works very well) as a reference implementation and at the free tds docs.
About Postgresql, I was joking at my very bad knowledge, but for the few I saw in docs, it seems to be a nice beast.
Leboncoin.fr runs everything on it. Yeah, a beast. Phil
Sqlite and Postgresql are good choices IMHO, Mysql not sure but as there is already a smalltalk native driver IIRC, it may be not too difficult (and it seems to be fairly used too).
As you, I'm a big fan of MSQL Server but keeps secret this information ;-)
Don't worry, I'll keep your secret secret :)
Olivier
-- Regards,
Alain
--
participants (5)
-
Alain Rastoul -
olivier auverlot -
phil＠highoctane.be -
Stephan Eggermont -
stepharo