Login | Register
My pages Projects Community openCollabNet
Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author theslack
Full name Jack Neely
Date 2006-08-31 10:30:11 PDT
Message Comments?

---------- Forwarded message ----------
From: Jared Greenwald <jared.greenwald@​oracle.com>
Date: Aug 31, 2006 1:15 PM
Subject: Re: Current with Oracle backend
To: Jack Neely <jjneely at gmail dot com>

Hash: SHA1

Actually, re: DB APIs, might want to consider using SQLAlchemy... Looks
like it has built-in support for the following:

    * Postgres: psycopg2
    * SQLite: pysqlite
    * MySQL: MySQLDB
    * Oracle: cx_Oracle
    * MS-SQL: adodbapi pymssql
    * Firebird: kinterbasdb

This would probably allow you to eliminate most of the db layer - it
also takes into account differences in the way that bindvars are
handled, so the only thing that would be db-specific would be the

Just a thought.

- -Jared

Jack Neely wrote:
> The logger.py module that everything imports has been ported to use
> python's logging stuff.
> Jack
> On 8/30/06, Jared Greenwald <jared.greenwald@​oracle.com> wrote:
> Something I just noticed. You mentioned transitioning to the logger
> module, but in reading the pysqlite.py code, it seems to be still using
> the home-brew logger method. Is this intentional?
> -Jared
> Jack Neely wrote:
>> Yeah...in theory you could create the database by hand. You got it.
>> The pyc/pyo files you don't need to worry about. Python will manage
>> those as it needs. (Of course, propper RPM packaging takes a bit more
>> work, but the current spec file should work. There have been a lot of
>> changes sence 1.7.4 so not sure...)
>> Jack
>> On 8/29/06, Jared Greenwald <jared.greenwald@​oracle.com> wrote:
>> But other than just calling the initdb routine, there's really nothing
>> more to it, right? (As in, if I created the db off to the side, it
>> shouldn't matter, right? As long as it had the correct layout.)
>> I had previously made changes to currentdb.py (to add the new db type)
>> and created my own oracle sub-dir (of db) and created the __init__.py
>> and oracle.py files.
>> -Jared
>> Jack Neely wrote:
>>> cinstall calls current.db.currentdb​.CurrentDB().initdb(​) which calls
>>> the initdb() method of the specificDB object that is associated with
>>> that specific database, in your case Oracle.
>>> You may also want to see current/db/__init__.py.
>>> Jack
>>> On 8/29/06, Jared Greenwald <jared.greenwald@​oracle.com> wrote:
>>> Where is the initdb code located? I'm thinking that there might be
>> some
>>> issues with how it creates the db, but I want to check over the code
>>> first.
>>> Thanks for all the help. I really appreciate it.
>>> -Jared
>>> Jack Neely wrote:
>>>> Jared,
>>>> Yeah...you need to edit the current.conf config file, cinstall
> initdb,
>>>> create_channel, add_dir, and scan. Current will still touch the
>>>> filesystem (some files are named from a datestamp) but it knows what
>>>> to do if stuff is already there.
>>>> Jack
>>>> On 8/29/06, Jared Greenwald <jared.greenwald@​oracle.com> wrote:
>>>> Excellent. Works like a charm. If I'm going to change databases,
>> so I
>>>> need to re-configure anything other than having the schema setup? I
>>>> imagine that I'll have to create_channel, add_dir, scan, etc... to
>>>> re-setup this channel...
>>>> -Jared
>>>> Jack Neely wrote:
>>>>> Jarad,
>>>>> up2date --showall wont work until the initial cadmin scan. I can
>> tell
>>>>> you haven't done the scan because of this
>>>>> 'lastupdate': None
>>>>> in the logs.
>>>>> The scan wont work until apache has the proper permissions for
>>>>> /export/current
>>>>> Jack
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org