[repoman] platform thoughts

[Dan McGee]

On 7/1/07, Essien Ita Essien <me at essienitaessien.com> wrote:
> Paul Mattal wrote:
> > 1) I've started working in python for repoman. I think it's very
> > flexible and likely to be a good choice for the project. Anyone want to
> > lobby for another language before we settle on python?
>
> Python +1 :)
+1

> > 2) I am settling on sqlite as squarely between a big RDBS like mysql and
> > postgresql (which I'd like to avoid) and a text file (which may be
> > underpowered for our purposes). What do people think about sqlite?
>
> I've programmed against Sqlite and MySQL pretty regularly and I'm okay
> with either one, though benchmarks seem to show that SQLite is faster
> than (untuned?) MySQL for a lot of common operations. Not sure about
> MySQL Embedded comparisons though (last time i programmed against this,
> had a pretty weird C api :) ).
>
> I'd just say... sqlite.

I'd just say...KISS. This is most important. I would think it is best
to make something as DB-agnostic as possible, which ties into the next
point, although there is a bit of discontent against using an ORM,
which I think is the best step to keeping this project from dipping
into DB-backend specific details. For example, the main archlinux.org
server, running repoman at some point, may want to use MySQL for the
DB stuff.

> > 3) I would like to use a simple ORM to do *most* things. It's just less
> > code to get wrong. Obviously, we could still write pure SQL against the
> > db at any time. What do people recommend for a python ORM that supports
> > sqlite? SQLObject is around, the django db api is another option (easy
> > addition of web interfaces later), and there's also SQLAlchemy, I think,
> > and maybe one or two others. Thoughts?
>
> I've had bad experiences with SQLObject :(
>
> I use it for a lot of not so complex projects with pretty limited data
> relationships. Once I begin to need to do some serious normalizations,
> JOINs, and other stuff that I could do at the database level, SQLObject
> actually begins to hinder me.
>
> There are also other funny behaviourisms that depend on how you name
> your tables. And did I mention that writing complex JOINs in SQLObject
> just blows?

But are we ever going to have to do this? Once again it is hard to shy
away from details, but I personally don't see our database being a
gigantic monster here which we will query to death.

> I've almost personally sworn off ORMs for medium to huge projects, till
> i had to write a small library to allow me work with SQL and still
> benefit from Python representation of objects.
>
> I seem to hear that SQLAlchemy doesn't suffer from all the problems I've
> encountered with SQLObject, and i've never touched Django's ORM b4. If I
> have sometime on my hands this week, I'll play around with SQLAlchemy
> (though its obviously not going to be as good an opinion as someone
> who's used it for more than 4 to 5 serious real life projects)

I just don't have the experience with them, so I can't offer a whole
lot besides my thoughts above.

-Dan