Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: Fwd: Current with Oracle backend

Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

current
Discussion topic

Back to topic list

Re: Fwd: Current with Oracle backend

Reply

Author Pauline Middelink <middelink at polyware dot nl>
Full name Pauline Middelink <middelink at polyware dot nl>
Date 2006-09-01 09:05:00 PDT
Message On Fri, 01 Sep 2006 around 11:14:13 -0400, Jack Neely wrote:
> >Well, the interface does not seem to change a lot,
> > db -> connection -> cursor -> execute.
> >They do claim to have an exceutemany, which in some cases could
> >really be useful!
> ><pauze>
> >It does seem to be more general in use, translating the
> >queries and stuff to the selected engine on the fly.
> >Not a lot of work though...
> >
>
> Folks,
>
> Seems I hadn't quite gotten to the part where SQLAlchemy documents how
> to execute standard SQL. Which does make it less work than having to
> port SQL to the python sql constructors. Could it be setup has
> another database type?

Well, probably, but we will be missing out on lots of features we
than can't use because we need to program for the stupidest interface :(
(like the use of the ?-bindings and executemany)

Whereby sqlalchemy seems to have a feature rich interface and does the
translating to 'stupid' databases below the surface.

> Here's the thing: For this dev cycle (and my own goals) I don't have
> time to do any major re-work of the database layer. I am interested
> in SQLAlchemy and if I was starting from scratch now, that's probably
> what I would use. So, if folks want to work on a SQLAlchemy branch I
> will be supportive. But I don't see accepting it until the next dev
> cycle.

But... Err, how to put this. We are already 2+ years in dev cycle 1.7.x?
What will be the timeframe for 1.9.x? I mean if we have to wait like
1.5 years, than its not worth the effort to track the changes in the
base 1.7 to the SQLAlchemy branch.

I think, before we go anyfurther, we need to see how big an impact
it will be. Judging for the docs, it's a low-level impact. So, i'm
willing to wrap up a little patch during the weekend so we know what
we are talking about. The decision to include it yes/no can than be
made on more facts.

> Also, all the filesystem scanning/manipulation needs to come out of
> currentdb.py and go into the Application layer. Something else to
> keep in mind.

Like putting _scanfilesystem and consorts in channels.py?

(It still seems like lots of bouncing between app-layer and db-layer)

Take for example the join I do in updateInstaledPackages(), do I need
to replace that with 2 calls from the app layer to get the installed
and package nvre's. Do the sort and do yet another third db-call to put
the information back?

Dont get me wrong, I'm all for seperation of logic and db, but some
data-centric stuff seems ok in the db-layer.

Comments?

    Met vriendelijke groet,
        Pauline Middelink
--
GPG Key fingerprint = 2D5B 87A7 DDA6 0378 5DEA BD3B 9A50 B416 E2D0 C3C2
For more details look at my website http://www.polyware.​nl/~middelink
Attachments

« Previous message in topic | 4 of 5 | Next message in topic »

Messages

Show all messages in topic

Fwd: Current with Oracle backend theslack Jack Neely 2006-08-31 10:30:11 PDT
     Re: Fwd: Current with Oracle backend Pauline Middelink <middelink at polyware dot nl> Pauline Middelink <middelink at polyware dot nl> 2006-09-01 03:25:09 PDT
         Re: Fwd: Current with Oracle backend theslack Jack Neely 2006-09-01 08:14:13 PDT
             Re: Fwd: Current with Oracle backend Pauline Middelink <middelink at polyware dot nl> Pauline Middelink <middelink at polyware dot nl> 2006-09-01 09:05:00 PDT
                 Re: Fwd: Current with Oracle backend theslack Jack Neely 2006-09-01 10:07:06 PDT
Messages per page: