[repoman] platform thoughts

Essien Ita Essien me at essienitaessien.com
Wed Jul 4 18:17:02 EDT 2007


Dan McGee wrote:
> On 7/1/07, Essien Ita Essien <me at essienitaessien.com> wrote:
<snip>
> 
>>> 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.

Well... when I started out with my simple repobot (i should start
calling that implementation repostats or something) implementation I
quickly realised I needed to do some basic joins when in SQLObject
quickly became ungainly. But then again, this was mainly when garnering
the reports to present on the UI, so if we keep in mind that repostats
(formerly repobot :)), was mainly a statistical analytic tool, then we
may safely assume repoman won't need complex JOINs etc. and then again,
if we do need statistics, I won't advocate doing it in repoman, so Dan
may be right here... it may be a non-issue really.

> 
>> 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
> 
> _______________________________________________
> repoman mailing list
> repoman at archlinux.org
> http://archlinux.org/mailman/listinfo/repoman
> 





More information about the repoman mailing list