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....@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 >> <steph...@free.fr >> <mailto:steph...@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 >>> >>> >>> >>> >> >> > > >
