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
Mark, not sure if you're still checking this, but:
http://autumn-orm.org/news/autumn-0-4...
Posted by SuperJared
good post man thx
Posted by john
VUOoOk hi webmastters
Posted by john2025
I'm glad these guys didn't listen to the "don't reinvent the wheel" advice from above:
http://www.airtrax.com/vehicles/sidew...
If people didn't rework old inventions we'd still only be one step past the Stone Age, as most inventions are actually something old improved as opposed to truly, completely new.
Posted by Carl
Hey, just checking back in. You would barely recognize the code I grabbed from you. Thanks again for getting me started. I pretty much went from Python noob to semi-guru status over the course of augmenting the ORM to new heights of complexity and automation. I checked over your new version and it looks like you are keeping things simple. I, on the other hand, have put this thing to use to deal with all kinds of odd database design and always strove to make it do as much as possible FOR me so the usage code is fairly simple. This means it has become a behemoth. I also have some junky Zope specific stuff in there, but it's minimal.
I added automatic inheritance of ForeignKey values to the point of allowing one to even include ForeignKey values in the WHERE clause by simply including said filter in the constructor of a Model child. You can add a ForeignKey of a ForeignKey to a Model and it will figure out how to do the two links necessary to get there. Deletion prorogation is in there. Optionally you can have a ForeignKey generate a "bogus" record if no record is found. I also added a SubModel class, you add instances of it to a main Model and that Model will link multiple tables together and act like one big table for all intents and purposes. And automatic ForeignKey fk value validation.
Query.py supports automatic cacheing and filtering on properties of the Model which don't happen to be fields in the db (but with the same syntax). I added special Condition classes so that the filtering isn't always just equals.
user = User( type = Condition.Not('Admin') );
My model.py is 1700 lines long now.
Anyways, I see you've been making your own updates. I thought you had abandoned this. I'll have to check the new version out and see if there's anything cool I can nab. ;)
Posted by Mark
Hey Mark, thanks for the response. I certainly haven't given up on Autumn. But at the same time I haven't spent a whole lot of time on it since it suits my needs. Autumn is rooted in simplicity; that was my aim from the beginning. Other ORMs (notably SQLAlchemy) give you the freedom to do incredibly complex tasks and I certainly don't feel the need to impinge on that. Autumn's simplicity is what makes it useful for me. And apparently to you as well. A simple, small project makes it considerably easier to fork and grow a new project. I'm glad my code has helped you.
I do plan, however, to make some revisions to Autumn soon. I'm not sure of the timeline so you'll want to watch the GitHub page if you want to keep track:
http://github.com/JaredKuolt/autumn/t...
Posted by SuperJared
hey, it's really odd how a minimalistic intent can turn complex -- and then, boom, abstraction simplifies things again...
Good for you Jared for writing your own ORM -- I am trying out this python module at http://yserial.sourceforge.net
and learning a lot about persisting schema-less data (Python dictionaries) in SQLite.
Simplicity as to use and interface is the key, but the background computation has to be rigorous and fast!
Posted by Laslo
I just came across Autumn ORM. I am intrigued by the example usage I saw on the project site -- I have not actually tested it out yet. I would like to use it and also contribute to the development effort where possible.
Unfortunately, the github link http://github.com/JaredKuolt/autumn/ provided on the website http://autumn-orm.org/news/ .Also it seems like the site news has not been updated in a while since Dec 22, 2008 when v0.5.1 was released.
I discovered the Autorm (http://github.com/umidev/autorm) project which is a fork of Autumn ORM. It seems to have been worked on recently (in Q4 of 2009) so I'm hopeful that if this project is dead, at least it's ghost is still kicking.
I would appreciate any feedback regarding the status of the project.
Cheers!
Posted by Rudy Lattae