I had a talk with a Doctrine developer.

[chx] Are you familiar with db_rewrite_sql ?
[chx] It is used to add tables and conditions to existing queries to implement an access control
[jwage] Ok.. http://pastebin.com/m3ceac8b5
[chx] and more often than not people want to add fields, too
[chx] so
[jwage] ok, so if you want to add a field, use addSelect()
[chx] a) there should be an easy way to check which tables are already added
[chx] b) there should be an easy way to add additional tables
[jwage] ok, $query->exists()
[jwage] ok, $query->addFrom()
[jwage] $query->leftJoin(), $query->innerJoin()
[chx] c) there should be an easy way to add conditions
[jwage] ok $query->addWhere()
[chx] oh, once parsed you actually have an exists method?
[jwage] is that what you mean?
[jwage] yes..
[jwage] It is benchmarked, Doctrine is 95% covered by unit tests..
[jwage] Doctrine has a big following behind it, it will be the defauly orm in symfony 1.0
[jwage] whoops 2.0
[jwage] I have used Doctrine in over a dozen very large scale web applications..for very large clients...and it has been very successful..hundreds of others are using it too..
[chx] jwage: I was the one who integrated IXR and KSES to Drupal
[jwage] chx: the other benefit of using Doctrine is the db administration utilities it has
[jwage] it has a command line interface for managing your database, migrations
[jwage] data fixtures, schema files
[jwage] Model templates
[jwage] behaviors
[jwage] behaviors are things like Sluggable, Timestampable, Versionable, NestedSet, etc.
[jwage] Doctrine also enforces database integrity both at the db level and code level
[jwage] if you are using myisam it will enforce foreign keys in the code
[chx] jwage: YAML for schema, not bad.
[jwage] and data fixtures
[jwage] migrations can be generated by comparing your shcmea files to your existing database
[jwage] so you change your models and it will generate a migration class with the differences..
[jwage] You write your schema files and generate your models from the schema files at the command line.
[jwage] or, you can bypass schema files entirely and just write your models manually..
[jwage] i prefer schema files b/c they are way more portable and easier to define with less typing..
[jwage] dmitrig01: With the way we have Doctrine schema mapping setup you can define the schema information howeveryou want
[jwage] right now we have 2 ways of mapping schema info, with php code, or with yaml
[jwage] php code has things like hasColumn(), hasOne(), hasMany(), etc..
[jwage] http://svn.sympalphp.org/docrupal/trunk/models/generated/BaseNode.php
[jwage] i generated a set of schemas from the default database in Doctrine
[jwage] http://svn.sympalphp.org/docrupal/trunk/schemas/schema.yml
[jwage] those models were generated from that schema file above
[jwage] but, the schema is generated from the database and while it works, it is very verbose
[jwage] half the definitions there can be removed b/c of defaults
[jwage] typically i have one schema file for each table
[jwage] this is just generated directly from mysql
[jwage] so it exports absolutely every piece of schema info it has
[litwol] jwage: can you show a schema of cache table?
[jwage] http://svn.sympalphp.org/docrupal/trunk/schemas/schema.yml
[jwage] search for Cache:
[chx] jwage: would you mind if I would post the log of this talk?
[jwage] http://svn.sympalphp.org/docrupal/trunk/models/generated/BaseCache.php
[jwage] Not at all..
[jwage] and the cool thing about Doctrine is it has standards and conventions for naming of tables, columns, etc..but you dont have to follow it
[jwage] it has ways to define things if you dont follow the pattern..
[jwage] but if you do follow the pattern. doctrine can do lots of work for you by guessing things
[jwage] for example if User hasOne Contact
[jwage] and you have a contact_id on your User model
[jwage] it will automatically detect that
[jwage] and instantiate the relationship between the 2
[jwage] Doctrine has a team of ppl who have been using all diff. types of databases..and Doctrine uses PDO so we can swap out your current dbal to use PDO from Doctrine
[dmitrig01] jwage: could we somewhere define all keys to common tables?
[jwage] Yes, that is what Templates are for
[dmitrig01] jwage: to allow relationships
[jwage] you can do $this->loadBehavior('Common')
[jwage] or something like that
[jwage] behaviors: [Common] for yaml syntax
[jwage] and this template will load all the common relationships for that model
[jwage] i have Templates like Commentable, Sluggable, Searchable
[jwage] Taggable, etc..
[jwage] you can write anything you want as a behavior
[jwage] and reuse it in all of your models..
[jwage] We have lots of behaviors that come with Doctrine though..
[litwol] jwage: whats the lisense behind this?
[jwage] Timestampable, Sluggable, Searchable, Versionable, Geographable, Taggable, NestedSet, I18n
[jwage] LGPL it is compatible with Drupal :)
[jwage] It doesn't matter anyways..we'll change lol..
[jwage] We are open
[jwage] You can use Doctrine, fork it, share it, change it, contribute to it
[litwol] this part of drupal would be too important to get caught in lisense wars
[chx] you are not the first to change to GPL because of us
[chx] jQuery dual licensed too
[litwol] so it needs to be drupal way or the highway i think
[litwol] or not
[jwage] The license is so not important to us..i honestly have no vested interest in any license lol
[jwage] I want people to use Doctrine at all costs, b/c i understand the power of it. and php has needed something like Doctrine since its existence..
[jwage] I've used all the other so called "orm" solutions in php
[jwage] and they are not ORMs
[jwage] they are glorified database abstraction layers
[jwage] like Propel for example..
[jwage] it is not a rival of Doctrine
[jwage] Nothing is competing with Doctrine as of today in php
[jwage] the closest thing to Doctrine is in other languages like ruby and java..
[jwage] Like i said it has taken 3 years to develop a proper orm solution in php..
[jwage] Some people without knowledge of how to use doctrine have benchmarked it comparing it to other tools for php
[jwage] they benchmarked doctrine without knowledge of how to use it and take advantage of its production performance features
[jwage] If you take Doctrine out of the box, of course it is going to be slower b/c it has many performance options you can turn on and off..
[jwage] basically most of the critique has been done by ppl who don't know how to properly setup and use Doctrine
[jwage] we'd take care of this b/c when we implement Doctrine in drupal, we would set it up so it is the ideal setup
[jwage] also, Doctrine supports component binding. so I can setup multiple Doctrine connections and delegate certain models to certain db connections
[jwage] this is one of many many features hehe..
[jwage] but the bread and butter of Doctrine is DQL really
[jwage] which is also the bread and butter of Hibernate, the most well known ORM solution in the world..and Doctrine is based off of Hibernate
[chx] jwage: do you use lazy loading? if yes, how do you avoid SELECT N + 1 problems?
[jwage] yes
[jwage] we use lazy loading for everything
[jwage] and no, nothing is exponentially slow
[jwage] we used to have a data hydrating issue with it getting exponentially slower but we fixed it with some garbage collection
[chx] jwage: http://groups.drupal.org/node/8001
[jwage] it relaly only showed itself when dealing with hydrating thousands of records in to the models
[Druplicon] http://groups.drupal.org/node/8001 => Musings on a Data API => 10 IRC mentions
[chx] jwage: care to run over this?
[jwage] chx: sure anything specific?
[jwage] Just scanning over it, it looks like what he is looking for is Doctrine ;)
[chx] jwage: the "Ready, Set, Go"
[chx] jwage: loading a set of nodes... with multiple value fields...
[jwage] "Assuming that Author and Book are two separate entity types, we will execute one query to find the books we want (with its title), and then for each book we will execute another query"
[jwage] this is not a issue in Doctrine
[jwage] In DQL you can always get everything down to 1 query
[jwage] no matter how complicated
[jwage] Say you have User hasOne Contact, User hasMany Comments, User hasMany Phonenumbers
[jwage] and the structure is User->getContact() User->getComments() User->getPhonenumbers()
[jwage] so i would do a query like "FROM User u, u.Contact c, u.Comments cs, u.Phonenumbers p"
[jwage] that would hydrate the entire User model structure with the information from one query
[chx] so you build the big query based on the schema ?
[jwage] and when i do User->getPhonenumbers() it wold not query for it individually, it would be there from the main query
[jwage] chx yes..
[jwage] Doctrine is smart, we let it do as much work as it can
[chx] but then its not lazy loading? (which is fine)
[jwage] chx it has lazy loading capabilities
[jwage] if you dont join it in with a DQL query, it will lazy fetch it
[jwage] so basically, you can start with a simple query "FROM User"
[jwage] and $user->getContact() will fetch that contact record individually
[jwage] and then if you do "FROM User u, u.Contact", and you do $user->getContact(), it doesnt have to query for it b/c it is already there from the main query
[jwage] I have never not been able to get something down to 1 query
[jwage] I typically develop with simple queries initially, and i have high query counts on my pages
[jwage] then i go and optimize my main queries to join everything in i need until the query count is down to 1
[jwage] The connections are lazy loaded though, they aren't created until they are needed
[chx] and you apparently did some work already on converting Drupal database to Doctrine
[jwage] so when I do Doctrine_Manager::connection('mysql://root:@localhost/db_name', 'conn_name');
[jwage] the connection will be present in octrine memory, but the PDO instance is not created until it is needed
[jwage] chx: I made a very rough draft
[jwage] the code is also very high quality
[jwage] All of us are major oop, standards freaks
[jwage] Also, in the future Doctrine will be split in to 2 packages, the DBAL and the ORM
[jwage] so you can use Doctrine DBAL if you dont want the ORM
[jwage] the ORM requires the DBAL package
[jwage] Also, Doctrine has a super fantastic user manual..It is in book format
[jwage] and full api docs..
[jwage] the user manual will be a published book in the future..im still working on making that happen for the project ;)
[litwol] jwage: also the issue that must not be overlooked is, how to avoid making people learn yet another thing. this will raise the learning curve more
[jwage] chx: if i could sit you down in person and show you doctrine
[jwage] i know i can sell you
[chx] jwage: that's why you should come Boston
[jwage] what kind of upgrade options do you all offer?
[chx] jwage: data upgrade
[jwage] Doctrine migrations would be PERFECT for that
[jwage] we have guys at yahoo using Doctrine too ;)
[jwage] a friend of mine from yahoo did the doctrine design for me ;)
[chx] jwage: however. jQuery causes us major pain when they release a minor version which breaks backward compatiblity
[jwage] _o_o_: an ORM is a way to represent your relational database as a set of php classes
[jwage] with features like inheritance, polymorphism supported..
[_o_o_] jwage: k thanks for the comprehnsve answer :)
[chx] jwage: http://www.phpdoctrine.org/documentation/manual?chapter=dql-doctrine-que...
[chx] jwage: that introduction is a bit strange.
[jwage] what is?
[chx] jwage: apparently the pseudo-SQL is better than calling functions...??
[jwage] chx: i dont understand your question?
[jwage] ohh no
[chx] jwage: the page says, $users = $conn->getTable('User')->findAll(); is slower than $users = $conn->query('FROM User u LEFT JOIN u.Phonenumber p');
[jwage] basically, you can use the Query api for building DQL
[jwage] or you can just write your DQL strings
[jwage] getTable('User')->findAll() is == to "FROM User"
[jwage] so if you do $users = Doctrine::getTable('User')->findAll(); foreach ($users as $user) $user->getPhonenumber()
[jwage] it will query for the phonenumber with a second query
[jwage] but if you do "FROM User u, u.Phonenumber p" it will hydrate User->Phonenumber with the data from the main query
[jwage] we have magic methods built in to Doctrine which just generate Query objects
[jwage] like Doctrine::getTable('User')->findOneByUsername('jwage');
[litwol] what about table prefixes?
[jwage] not an issue
[litwol] can you do from("{user} u") ?
[jwage] You can have table name prefixes yes..
[chx] jwage: how?
[jwage] by setting an attribute on Doctrine
[litwol] link to doc please
[jwage] Doctrine_Manager::getInstance()->setAttribute(Doctrine::ATTR_TABLE_PREFIX, 'prefix');
[jwage] something like that
[chx] jwage: oh a BNF
[chx] jwage: I like BNF :)
[jwage] chx: BNF? sorry i am not up to date on lingo lol
[chx] jwage: http://www.phpdoctrine.org/documentation/manual?chapter=dql-doctrine-que...
[jwage] ahh ya..
[jwage] chx: the goal of DQL is for it to become a standard
[chx] BNF makes me warm and fuzzy :)
[jwage] in the future DQL parser could be written in c and be a part of php
[jwage] or
[jwage] DQL could be in an actual relational database
[jwage] mydql
[jwage] object oriented database
[jwage] the cool thing is iit would still be a relational database, so you have the same speed of mysql, but it has a oop layer on top of it
[jwage] b/c oo databases are notorious for being slow..
[chx] jwage: so I will take this talk edit and post on my blog
[jwage] Sounds good..
[litwol] jwage: and of course silly things like sql injection and other security is handled too
[litwol] ?
[jwage] litwol: lol of course. PDO handles this for us ;)
[litwol] ah yes, pdo
[jwage] it would be amazing if we made it this far without thinking of something like that ;)

Commenting on this Story is closed.