There's definitely a need for a 'great' PHP ORM. I've been rolling my own for a couple of years since I've never been satisfied with what's out there. Here's the kind of syntax/style I use on mine (that class definition is the entire code I need to write to get working abstraction).
If you're going to upgrade to 5.3 (which you should!), I would highly recommend Doctrine 2 (not 1, very different project). It's a loose port of Hibernate from Java and takes a very different tack then most PHP ORMs. The models have no mandatory base class, the pattern is more Data Mapper then Active Record, it allows batch flushing to the database, has associations, and has some really great features like inheritance mapping and an event hook system.
There are pieces to dislike (arguably DQL, soft deletes are almost impossible, etc) but so far, it's a huge step forward from the likes of Zend_Db_Table or Doctrine 1.
Yeah I've had a lot of experience with Doctrine. Had to roll my own orm on a previous project due to certain requirements and have been playing with orms since. Doctrine has a lot of nice standards and a good community around it.
I love Doctrine at work. I hate it at home. It's a great standardised system that that has a lot of great features we use, but for simple projects at home, it's far too cumbersome to set up.
I like the look of DumbledORM, although it takes a bit of a different approach to Idiorm (and its "child" project, Paris - http://github.com/j4mie/paris - which is an Active Record implementation with support for associations built on top of Idiorm in ~130 lines of code). I'm not really a fan of code generation at the best of times, and for a tiny ORM it seems a bit out of place.
I do like the idea of being able to save multiple rows, jQuery-style. I might just steal that..
Thanks, I've been looking for a Kohana-esque ORM that comes without the Kohana for smaller projects... paris looks like it fits the bill perfectly. Uses very similar configuration per-class: belongs_to, has_many, has_many_through. Awesome!
* do you write all your code without comments, or do you strip them out afterwards to get to save locs? imho you should forget the 200 loc constraint and make your code pretty instead - it looks anorectic. seesh, yes i know the 200 loc promise is your main selling point to make the project stand out ;)
* a namespace would be a good idea here. "Builder", "Db" and "ResultSet" aren't that uncommon.
* defining the connection credentials as a class with consts smells funny.
Nice but is there any mention in the article about support for just writing plain old SQL? I love the ideas of ORMs (my app now currently uses SQLAlchemy) but I find myself dropping back to SQL when things get a little complex. I think new age ORMs should leave support for dropping back to SQL. Cool project nonetheless.
I don't think they need to provide SQL support so long as they provide something that's equivalent. For example in C#, nHibernate has the Restriction classes (and Linq). They can be a little clunky compared to SQL but it can be fully type checked.
I checked the site, I checked Github, but I still have no idea what "ORM" means.
Wikipedia suggests several different meanings which seem to fit: Object-relational mapping, Object role modeling, Online Reputation Management, Online research methods, Outsourcing Relationship Management
Put as simply as I can put it, it's an abstraction layer in front of SQL.
The general logic (which I object to, though I still prefer ORM-based development) is that most of your class Objects relate to how you would store them in a database. Your 'User' object has a first name, a last name, a password, etc., which all map neatly to database records.
So, instead of doing "INSERT INTO users firstname, lastname, password) VALUES ('foo', 'bar', 'baz');", you create a user object:
There's definitely a need for a 'great' PHP ORM. I've been rolling my own for a couple of years since I've never been satisfied with what's out there. Here's the kind of syntax/style I use on mine (that class definition is the entire code I need to write to get working abstraction).
class Person extends Model {
const TABLE_NAME = 'people';
const TABLE_KEY = 'id';
}
$person = Model::find("Person", 1234);
$person->name = "James";
$person->save();
$persons_named_james = Model::find("Person", array("name" => "James"));
foreach($persons_named_james as $person) {
print $person->age;
}
$person = new Person();
$person->age = 26;
$person->save();
I should really upgrade to 5.3 so I could write Person::find(1234); instead.