Being brand new to Zope I may have misunderstood some of the things I have seen in the archives but ...it seems that the intention is to concentrate on Openlink ODBC for database connections. I have used Openlink for many years and would say that it is a fine product but I have serious doubts that it is the way to go for general database connections. (It's not Open Source either..) My particular background is Informix and I would love to use Zope, but there is no native interface. I'm happy to use ODBC during development but for a large scale implementation ? Perhaps its just prejudice but it is a prejudice which will be shared by PHB's everywhere. Also ODBC implies NT and that goes against the whole Open Source philosophy surely. Excuse my ignorance but since there is a Python interface to Informix does that not make it possible to link Zope to Informix directly ? Regards Richard Richard Moon richard@dcs.co.uk
Richard Moon wrote:
Being brand new to Zope I may have misunderstood some of the things I have seen in the archives but ...it seems that the intention is to concentrate on Openlink ODBC for database connections.
Where did you get thet impression ?? Maybe you mean the iODBC driver manager for Linux (and UNIX in general) that are currently maintained by OpenLink
My particular background is Informix and I would love to use Zope, but there is no native interface. I'm happy to use ODBC during development but for a large scale implementation ? Perhaps its just prejudice but it is a prejudice which will be shared by PHB's everywhere.
Also ODBC implies NT and that goes against the whole Open Source philosophy surely.
ODBC does not imply NT, ODBC is mostly ANSI SQL CLI .
Excuse my ignorance but since there is a Python interface to Informix does that not make it possible to link Zope to Informix directly ?
Yes, if you or someone else writes the missing piece - the ZopeDA. ---------- Hannu
On 2/4/00 6:46 AM, Richard Moon at richard@dcs.co.uk wrote:
Being brand new to Zope I may have misunderstood some of the things I have seen in the archives but ...it seems that the intention is to concentrate on Openlink ODBC for database connections.
This is true for commercial consulting contracts. We have not stated this in regards to other users.
I have used Openlink for many years and would say that it is a fine product but I have serious doubts that it is the way to go for general database connections. (It's not Open Source either..)
A simple survey of roughly 80 people implied only 3 cared about source, and I suspect only one of those would actually make a CHANGE to the source, so lets be careful of red-herrings here. You're using Informix (closed source) and then upset that the driver isn't open source? This is a bit of a troubling predicament. Do you have any particular objects that are non-philosophical as regards OpenLink?
My particular background is Informix and I would love to use Zope, but there is no native interface. I'm happy to use ODBC during development but for a large scale implementation ? Perhaps its just prejudice but it is a prejudice which will be shared by PHB's everywhere.
An unfounded prejudice. Some simple benchmarks show that OpenLink is as fast as using native Oracle SQL*NET interfaces, and sometimes noticeably faster. There might be some small hit on a "single machine" implementation, but this is unlikely to be a performance sensitive installation in the first place.
Also ODBC implies NT and that goes against the whole Open Source philosophy surely.
It implies no such thing. 1) ODBC is a specific flavor of X/Open CLI which is a standard interface to relational databases and is native interface for IBM DB/2, 2) NT is not specifically anti-source, just the community is not specifically PRO Open Source. This is a political discussion that is inappropriate for any technical forum. Call it X/Open CLI, that's what we call it. OpenLink calls it UDBC, but it's all the same thing underneath. In this case, Microsoft is *way* ahead of the UNIX community in "open standards." They actually changed ODBC back after v1 to track the standard.
Excuse my ignorance but since there is a Python interface to Informix does that not make it possible to link Zope to Informix directly ?
You could probably modify the Oracle DA piece to make it work trivially. We simply don't have a customer asking for it, and that means paying customers. We've also found that there is no such thing as an "unsupported product" from us. People expect it to be supported even when we "throw it over the wall." We'd be ecstatic if the Python community made more adapters, but we currently support Sybase and Oracle, and its a pretty big burden given we add no value to the equation. If you were to offer an Informix adapter that you supported, all the Informix people would love you, as would we. ;-) Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
Christopher Petrilli writes:
We'd be ecstatic if the Python community made more adapters, but we currently support Sybase and Oracle, and its a pretty big burden given we add no value to the equation. If you were to offer an Informix adapter that you supported, all the Informix people would love you, as would we. ;-)
Note that writing a DA isn't documented, and there's no test suite for verifying a DA's correct operation. We use an mxODBC DA that I hacked out of the Oracle DA (I haven't yet gotten around to releasing it -- I know, I know...). A little while ago, it started occasionally raising an exception about the connection being broken and I haven't yet tracked down the cause. It's probably a bug in my code, but it might be a bug in the Oracle DA that I used as a starting point. Maintaining sychronization with the Oracle DA would be tedious. I found that the Oracle DA doesn't really have to change very much to use mxODBC. Maybe this is an argument for pushing the whole Oracle DA into some standard product, where you'd write a single adapter module for each new database, rather than copying the whole DA over and over again. -- A.M. Kuchling http://starship.python.net/crew/amk/ The universe is full of magical things patiently waiting for our wits to grow sharper. -- Eden Phillpotts
On 2/4/00 12:06 PM, Andrew M. Kuchling at akuchlin@mems-exchange.org wrote:
Christopher Petrilli writes:
We'd be ecstatic if the Python community made more adapters, but we currently support Sybase and Oracle, and its a pretty big burden given we add no value to the equation. If you were to offer an Informix adapter that you supported, all the Informix people would love you, as would we. ;-)
Note that writing a DA isn't documented, and there's no test suite for verifying a DA's correct operation.
Actually it has been documented for several months, I wrote a HOW-TO and announced it to the list with a resounding THUD. I'm currently working with our ODBC DA effort in a closed loop to try and improve it. You can find it here: http://www.zope.org/Members/petrilli/WritingADA It was put up 11/3/1999. As for no test suite, this is a correct assertion, and we are working to create regression code for all things, but it's a slow process.
We use an mxODBC DA that I hacked out of the Oracle DA (I haven't yet gotten around to releasing it -- I know, I know...). A little while ago, it started occasionally raising an exception about the connection being broken and I haven't yet tracked down the cause. It's probably a bug in my code, but it might be a bug in the Oracle DA that I used as a starting point. Maintaining sychronization with the Oracle DA would be tedious.
It shouldn't be hard to use it as a basis for what needs done though, especially after reading the HOW-TO.
I found that the Oracle DA doesn't really have to change very much to use mxODBC. Maybe this is an argument for pushing the whole Oracle DA into some standard product, where you'd write a single adapter module for each new database, rather than copying the whole DA over and over again.
This was the goal of the DB-API, but we don't need most of it. This is the point of ODBC as well. Push the standard further down the stack: +-------------+ | ZOPE | +-------------+ | SQL Methods | +-------------+ | DA | +-------------+ | DB-API | +-------------+ | OCI | +-------------+ | Oracle | +-------------+ Instead what we'd really like to see is something more abstract below DB-API. I talked a lot with the ActiveState guys at the conference on this one. It's a long road, but Python is sorely lacking in comparison to Perl in this arena, and we can't solve it alone. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
Hi Chris You asked if I had any non-philosophical objections to Openlink and I have to say no I don't - it's a good product. I've been using Openlink multi-tier for several years now on several clients sites and it has behaved faultlessly. We have found that upgrades are easy and smooth. Support is truly excellent as well - even if you are running the no-cost licence. I don't have much information on performance as we use native Informix connections for our programs. Openlink is used by Access and Excel users mainly - on an occasional basis -though we have not experienced any noticeable performance problems. Because we are only using ODBC for read-only selects on the database I cannot comment on how well it supports all the features which Informix provides. Is it likely that in the near future you will be releasing ZODBC on non Win32 clients ? As for your 'troubling predicament' comment - don't forget that Informix was around long before open source was thought of - as was I :-). I don't see that because we are starting from a given point, we should not try to move in a preferred direction. Regards Richard At 11:49 04/02/00 -0500, you wrote:
On 2/4/00 6:46 AM, Richard Moon at richard@dcs.co.uk wrote:
Being brand new to Zope I may have misunderstood some of the things I have seen in the archives but ...it seems that the intention is to concentrate on Openlink ODBC for database connections.
This is true for commercial consulting contracts. We have not stated this in regards to other users.
I have used Openlink for many years and would say that it is a fine product but I have serious doubts that it is the way to go for general database connections. (It's not Open Source either..)
A simple survey of roughly 80 people implied only 3 cared about source, and I suspect only one of those would actually make a CHANGE to the source, so lets be careful of red-herrings here. You're using Informix (closed source) and then upset that the driver isn't open source? This is a bit of a troubling predicament.
Do you have any particular objects that are non-philosophical as regards OpenLink?
My particular background is Informix and I would love to use Zope, but there is no native interface. I'm happy to use ODBC during development but for a large scale implementation ? Perhaps its just prejudice but it is a prejudice which will be shared by PHB's everywhere.
An unfounded prejudice. Some simple benchmarks show that OpenLink is as fast as using native Oracle SQL*NET interfaces, and sometimes noticeably faster. There might be some small hit on a "single machine" implementation, but this is unlikely to be a performance sensitive installation in the first place.
Also ODBC implies NT and that goes against the whole Open Source philosophy surely.
It implies no such thing. 1) ODBC is a specific flavor of X/Open CLI which is a standard interface to relational databases and is native interface for IBM DB/2, 2) NT is not specifically anti-source, just the community is not specifically PRO Open Source. This is a political discussion that is inappropriate for any technical forum.
Call it X/Open CLI, that's what we call it. OpenLink calls it UDBC, but it's all the same thing underneath. In this case, Microsoft is *way* ahead of the UNIX community in "open standards." They actually changed ODBC back after v1 to track the standard.
Excuse my ignorance but since there is a Python interface to Informix does that not make it possible to link Zope to Informix directly ?
You could probably modify the Oracle DA piece to make it work trivially. We simply don't have a customer asking for it, and that means paying customers. We've also found that there is no such thing as an "unsupported product" from us. People expect it to be supported even when we "throw it over the wall."
We'd be ecstatic if the Python community made more adapters, but we currently support Sybase and Oracle, and its a pretty big burden given we add no value to the equation. If you were to offer an Informix adapter that you supported, all the Informix people would love you, as would we. ;-)
Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
Richard Moon richard@dcs.co.uk
participants (4)
-
Andrew M. Kuchling -
Christopher Petrilli -
Hannu Krosing -
Richard Moon