It was just a thought, I also remembered that there was a problem with
the single threaded approach of the VM. With ODBC FFI, it is very easy
for a simple application to lock itself with two connections with Sql
server or Oracle.
I think it was a motivation for DbxTalk development : doing db calls in
another thread, the same as it is for socket IO (perhaps it could be
done with nativeboost/odbc ?).
Developing native drivers (like type 4 jdbc drivers in java) in Pharo is
probably a very good solution, but will require lot of work and multiple
specific skills (probably someone developing-maintaining driver-x/db-x,
another the driver-y/db-y and so on).
Regards,
Alain
Le 11/01/2015 09:29, stepharo a écrit :
Le 10/1/15 14:47, Alain Rastoul a écrit :
Hi,
Nice document, however, about ODBC support column,
looking at and old (Pharo 1.3) image I have on my pc, I can see:
ODBCLibray>>moduleName
"Return the name of the module for this library"
SmalltalkImage current platformName = 'Win32' ifTrue: [ ^ 'odbc32' ].
SmalltalkImage current platformName = 'unix' ifTrue: [ ^
'libodbc.so' ].
^ self error: 'Don''t know the ODBC library name'
I thought odbc was supported under linux in the FFI ODBC package.
odbc rocks under windows, for non dotNet apps, (my opinion), and MS
has released an Mssql odbc driver for linux (They say they love linux
now :) ).
http://www.microsoft.com/en-us/download/details.aspx?id=28160
Oracle is also supported for 12 (I think at least since 10g)
https://docs.oracle.com/database/121/ODBCR/toc.htm#ODBCR101
Could it be interesting to re-investigate ODBC support ?
No idea :)
I'm not expert
Or DbxTalk is the Pharo standard (and it doesn't mind) ?
What oliier told me is that organizations reluctant to add extra
librariesto deploy app so
having some good native drivers would be better.
Stef
Regards,
Alain
Le 10/01/2015 11:32, stepharo a écrit :
Le 10/1/15 10:59, Stephan Eggermont a écrit :
Stef wrote:
May be this is the time to improve this package :)
I'm sorry I have no DB experience.
As part of the consortium agenda for this year we have
- better ffi
- better db support
Moving to Levente's PostgreSQLv3 and migrating that
might be a better idea. He has been using it in production
systems for a long time AFAIK.
when I meant db support it is not limited to one implementation.
Olivier Auverlot started to do a document listing all the solutions and
their status.
https://docs.google.com/spreadsheets/d/1uD6UFmwCJxAkOC9tlvdJsHtt10C0KHJ6Zp8WmfXpaR4/edit#gid=0
Add the information avout SQLv3
Now I do not get it.
Did you port it to Pharo?
The code mirror is very interesting. Porting it needs
someone with close access to Opal/old compiler knowledge.
The way it works now in Squeak looks ideal for someone
with a PostgreSQL background. Using a code browser
to edit plsql, and having a directly mirrored smalltalk
class for each table.
http://forum.world.st/Status-of-PostgresV3-td4780110.html
I have verified that the connection works and that I can get
data out of postgres.
Missing:
- switch the code highlighter from smalltalk to one
for plsql in nautilus.
- connect to glorp
- (later) add a real plsql parser (petitsql?)
Stephan
