Yet Another Python ORM
February 25, 2008
I’ve developed a Python ORM that is intended to be a lightweight, high-performance alternative to SQLObject, SQLAlchemy, the Django ORM, etc. Each of the preceding projects attempts to implement a comprehensive feature set. This ORM, however, is intended to be minimal, with as minimal of a configuration as required.
Please take a look at it here ›
Does the syntax look okay? Any ideas for a name? All the ideas I have for names are: MiniORM, MicrORM, AutORM and Autumn, because the last one sounds nice.
Add your comment
No HTML; Only URLs and line breaks are converted.
Comments
Why did you settle on [offset:limit] syntax for slices instead of a more expected [offsetmin:offsetmax]?
[20:10] does not seem very understandable in the middle of other Python code.
Posted by Patryk Zawadzki
Good point. I'll make the change.
Posted by SuperJared
I looked at your usage examples, and it all looks very similar to SQLObject. Can you elaborate on exactly how your new ORM is different? (I'm not trying to suggest one or the other is better, I'm just curious) I would just read the source code, but I doubt I'd be able to understand most of it.
Posted by Justin Voss
has potential.syntax looks good so far.
sometimes ya just need a minimal set to get an idea up and running. althought it's not much work to do the same in these other frameworks.
but keep it up! new ideas are always good for the community :)
Posted by kevin
it seems nice for a simple mysql orm. Do you plan to create more allowed relations?
Posted by matt
Nice code.
But would be nice to define fields and their types, using table introspection you have one more hit in the database for each Model object.
Also a simple mechanism for database driver would be nice.
I've liked the simplicity, congrats, keep up the good work.
Nuno
Posted by Nuno Mariz
i kind of like the "Autumn" name.
What does it need?
PostgreSQL & sqlite support. the latter is great for development while many prefer the former for deployment.
Syntax looks nice.
Posted by ka2
Justin, I'll make a post about the details on this orm soon.
Kevin, thanks, I definitely want to keep this project moving.
Matt, One planned feature is the Many to Many relation. Other than that, though, I think using the Query.sql method, which returns a dict based on the SQL output, would normally suffice for the really complex stuff.
Nuno, It's one query when the Model itself is created, not instantiated, so I think it's certainly worth the overhead. Plus, part of the reason I created this project was to have an ORM that didn't require defining fields.
ka2, Postgres and SQLite are coming, hopefully sooner than later. Fortunately I'm actually using unittests so I'll know what breaks and when.
Posted by SuperJared
Nice stuff! I started hacking together something like this for a project I'm working on, but now I think I'll use your code since you are a lot further along, and it's better implemented (more general).
I vote for Autumn as a name.
Also ooking forward to the Postgres support.
Posted by Jamie Bullock
We already have enough ORMs in the world. Reinventing wheels seems to be the primary focus of some Python developers. You guys have too much time. Better use and extend modules that are already available!
Posted by ORM Hater
I like it!
The syntax is clean and your attitude against
feature creep gives me hope for this project.
Don't listen to Nuno. Db-introspection is a killer feature and one Db-hit per model during application startup is a non-issue.
I (like everybody else) am sick of duplicating meta-data all over the place. There should be one canonical source for schema information. That can be in code, like django, or it can be introspected from the Db, like you do. Mixing these two should be kept to a minimum and only where absolutely inevitable (e.g. constraints that cannot be expressed in SQL/DDL alone).
On that note I wonder why, in your code example, the
table relations (OneToMany('book')) have to be repeated in
code? With an introspecting ORM I'd expect to run without
declaring a class at all. Ofcourse there must be a way
to modify the auto-generated classes and inject additional constraints - but basic stuff like ForeignKeys can be determined from the DDL.
Anyways, I think you're on a good path and I'll keep an eye on this. Thumbs up! :-)
Posted by moe
Looks like it is inspired by Django ORM to some point. And for me -- this is Good(tm). ;)
Posted by zgoda
maybe this would be of interest? https://storm.canonical.com/
Its another fast & simple python orm.
Posted by ka2
Sorry, that's a waste of manpower. We have already enough half-backed ORMs. We have solutions that work. Why do you guys always have the need for reinventing wheels?
Posted by ajung
Because I wanted to. Creating this ORM taught me quite a bit about Meta classes, the Python DB API, as well as some other trickery.
Sorry I made you so mad.
Hope you're not crying.
Waaaah.
Posted by SuperJared
Actually, that was rude. I really am sorry.
Posted by SuperJared
I started writing my own ORM thing for an existing database. Then I randomly found yours and decided it had a few cool python tricks my noob mind hadn't thought of. So I'm using your code, but need to drastically modify it and upgrade it. I think I've got a relatively elegant solution for the ManyToMany problem, which is simply to use the OneToMany with inheritance of properties. I had to upgrade the code to support a pk = ['item1_id', 'item2_id'], so now you have the control of altering the record in the manytomany table (I have stuff in there other than keys), but with the inheritance of properties from its child table, you have the convenience of accessing members without going group.usergroups[0].user.blah. You can just go group.users[0].blah.
I also added a little junk so you can just write...
usr = User(432)
if all you want is the one record (which is 90% of my database usage).
Anyway, let me know if you want my mods to your code once I'm done. I'll watch this thread.
Posted by Mark
Mark, sounds great! I've not worked on this for a little while simply because I've been working on other things so I'd love to see what you've done. Send me an email through my contact form when you can!
Posted by SuperJared
My boss made me make all the automatically added fields read-only by default so sub-classes of Model would have more "control" over the setting of those values. This came about before I was done with my mods to your code, so if you still really want this kinda ugly and no longer simple version of your thing, I'll send it over when I'm done.
Posted by Mark
Just a tip: you should probably handle cases of the instance parameter being None by returning something, rather than raising an exception, in the OneToMany and ForeignKey __get__() methods. I just spent the last 3 hours tracking down why help(SomeChildOfModelWithForeignKeys) wasn't working. I changed them to just return self.model when instance is None.
Posted by Mark
Also, in ModelBase.__new__, on the line...
if not getattr(new_class, 'Meta', None):
new_class.Meta = Empty()
You should remove the parens of "Empty()" because otherwise the child classes that don't specify a Model get an INSTANCE where the ones that do define Model get a CLASS for Meta. This doesn't become a huge issue, of course, until, like I did, you start adding staticmethods to Meta.
Posted by Mark