[DB-SIG] Persistent Storage of Objects
M.-A. Lemburg
mal@lemburg.com
Tue, 04 Apr 2000 18:27:09 +0200
"Andrew M. Kuchling" wrote:
>
> M.-A. Lemburg writes:
> >everybody has their own specific needs. The range of applications
> >is huge: from simple dictionary like interfaces to tables to
> >complete nested object hierarchies with auto-load and -store,
> >version control and all the goodies in that bag. Plus maybe
> >meta-information control to build search engines on top of the
> >stored objects.
>
> True, but maybe a useful middle ground could be implemented. Maybe
> something like Tangram (http://www.tangram-persistence.org/) -- you'd
> have a simple schema language for laying out classes, their
> attributes, and the relations between them, and then have code to
> store objects in a set of DB tables.
Thanks for the pointer.
> >I'd rather like to see a DB API compatible JDBC interface...
>
> Is there anything about that problem that needs discussion, though, or
> is it a simple matter of programming?
No, just some implementors with some time on their hands ;-)
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
Return-Path: <guenter@ubka.uni-karlsruhe.de>
Delivered-To: db-sig@python.org
Received: from mailhost.rz.uni-karlsruhe.de (mailhost.rz.uni-karlsruhe.de [129.13.64.98])
by dinsdale.python.org (Postfix) with ESMTP id EFE901CE71
for <db-sig@python.org>; Thu, 6 Apr 2000 08:06:43 -0400 (EDT)
Received: from ubkadec2 (ubkadec2.ubka.uni-karlsruhe.de [129.13.130.35])
by mailhost.rz.uni-karlsruhe.de with smtp (Exim 3.02 #1)
id 12dB5w-0001W9-00; Thu, 06 Apr 2000 14:09:08 +0200
Received: from ubkaaix6.ubka.uni-karlsruhe.de (ubkaaix6) by ubkadec2
(5.65c8/IDA-1.4.4); Thu, 6 Apr 2000 14:09:06 +0200
Received: by ubkaaix6.ubka.uni-karlsruhe.de
(5.65c8/IDA-1.4.4); Thu, 6 Apr 2000 14:09:05 +0200
Date: Thu, 6 Apr 2000 14:07:20 +0200
From: Guenter Radestock <guenter@ubka.uni-karlsruhe.de>
To: db-sig.python.org@ubka.uni-karlsruhe.de
Message-Id: <20000406140720.A34704@ubkaaix6.ubka.uni-karlsruhe.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.5i
Resent-From: guenter@ubka.uni-karlsruhe.de
Resent-Date: Thu, 6 Apr 2000 14:09:05 +0200
Resent-To: db-sig@python.org
Resent-Message-Id: <E12dB5w-0001W9-00@mailhost.rz.uni-karlsruhe.de>
Subject: [DB-SIG] DCOracle number handling still broken?
Sender: db-sig-admin@python.org
Errors-To: db-sig-admin@python.org
X-BeenThere: db-sig@python.org
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: SIG on Python Tabular Databases <db-sig.python.org>
Hello,
I have used the now unsupported oracledb-0.1.3 in the past to create
some statistics from a database with the commands:
cursor.execute('select avg(something) from somewhere')
text = 'blah %.2f blah' % cursor.fetchone()
Some time last year I converted to DCOracle, version 1.2.1 and now I see
this does not work anymore (doesn't give an error, either). Aparantly,
DCOracle returns every number truncated to an integer (again: this would
work better with the old old oracledb.) I found that where svrmgrl
returns 1.30436094, DCOracle will return (1,) as a result to the same
select.
I have downloaded a newer version (DCOracle-1.3.0) some time ago but I
am not sure if this is fixed. Compiling DCOracle for a specific Oracle
under AIX (4.2.1, Oracle 7.3.4) is no simple thing and I only managed to
get a working version after throwing out shared library support and
creating a giant python executable with all oracle libs statically
linked.
Is there a workaround to this problem that does not require rebuilding
Python? Is this problem known and fixed? I failed to build DCOracle as
a shared module for AIX 4.2.1/Oracle 7.3.4 because some Oracle
networking lib needed a very old TCL/TK lib and I did not have a shared
version of this; has anybody done this successfully before?
- Guenter
--
Guenter Radestock, Universitaetsbibliothek Karlsruhe
guenter@ubka.uni-karlsruhe.de
http://www.ubka.uni-karlsruhe.de/~guenter