There are many different ways of modeling data. They all have their place, and all have places where they are a poor fit.
The spectrum of options below are defined mainly by the degree to which they differentiate between read and write models, and correspondingly how powerful-but-also-complex they are. "Model" in this case usually corresponds to a class, or a class with one or more composed classes.
It's been five years since I had a major life change. Five years since I finished grad school, found Drupal, and joined the team at Palantir.net, all within a few months of each other. I've learned far more in the past five years than in the seven before it in college and graduate school, both technically and socially. Having a real job will do that to you.
But, it has been five years and it's time for me to move on before I get too settled and lose all forward momentum in my career.
Do you have a Drupal module you want to upgrade to Drupal 7?
Do you want to know how to leverage the Drupal 7 database layer to make your module better?
Will you be at DrupalCon?
There should be about 500 of you that meet that criteria, by my estimate. More than enough for a BoF. :-)
There has been some discussion in recent days regarding Object-Relational Mappers (ORMs), Drupal, and why the latter doesn't use the former. There are, actually, many reasons for that, and for why Drupal doesn't do more with the Active Record pattern.
Rather than tuck such discussion away in an issue queue, I figured it better to document a bit more widely.
Unless you've been living under a rock for the last six month, you should have already heard about Drupal 7's new-and-shiny database layer, DBTNG. That was only the beginning, though! Much has happened since then to the database, and there's much yet to do. That's where you come in...
OK, I admit it. I'm not the most active Cubs fan around. I wouldn't say I'm a fair weather fan (the Cubs don't have fair weather that often) but I don't follow the team that closely. Perhaps I should start doing so, because I think this may be our year.
No, it's not because this is the 100th anniversary of when the Cubs last won the World Series. It's because the Databases: TNG patch for Drupal 7 has finally landed.
And there has been much rejoicing.
Drupal 7 is shaping up to be the most modern Drupal ever! (Now there's a silly title if I ever heard one...) Not only are we upping the system requirements to PHP 5.2 and MySQL 5.0, but PostgreSQL users will now need PostgreSQL 8.1 at least.
The new database system for Drupal 7 that I've been talking about for the past few months is nearly ready for submission. With chx's visit to Chicago we were able to refactor it for far better modularity and cleanliness. As of yesterday, the system is able to navigate around Drupal, submit forms, create and edit nodes, and view the insanely heavy modules admin page. I still need to make it work with the installer, but it's looking very promising. A very recent copy of the new code base, pre-Drupal-integration, is available in my sandbox.
Here's a brief list of the features it offers:
For those who may not have noticed it, it looks like Drupal 7 is going to require not only PHP 5.2, but MySQL 5.0 as well. It makes sense to do. Drupal 7 won't actually ship for another year, by which point MySQL 4.1 will be on life support anyway. It will also lose all support during the Drupal 7 life cycle. So if you're planning a new server, get ahead of the curve and Go MySQL 5! :-)
Drupal 7: The version that gets over the 20th century.
So, Dries wants to know what our Drupal 7 battle plans are. I think this is the first version where I'll have explicit battle plans before hand rather than just "whatever I come up with along the way". :-) So, for those playing along at home, here's my goals for Drupal 7: