[Solar-talk] Changes afoot: a new Model class

[Paul M Jones]

On Feb 8, 2007, at 9:43 AM, Travis Swicegood wrote:

> Note: I put this together yesterday shortly after the original  
> post, but
> had some issues with my mail server...  Here they are again:

And my reply at the time was this:

=== Original Reply ===

 >> The idea is to start developing something along the lines of the
 >> Ruby- on-Rails "ActiveRecord" class.
 >
 > One of these days, I tell ya... I'm going to collect all of my
 > lamentations on RoR's "ActiveRecord" (as opposed to the "Active
 > Record" which is useful) and it'll be enough to change the tide.  I
 > swear it :-)

Man, I *so* know what you're saying.  I hate that they adopted that
name.


 >> * Reads the schema from the database, creates the schema if it
 >> doesn't exist, and keeps the schema in a cache if one is
 >> available  (to minimize database hits).  This means you won't need
 >> to define  $_col beforehand, you can just point the Model to a
 >> table and it will  get everything it needs.
 >
 > Couldn't in inflect this from the object name by default?  That's
 > so very convention over configuration.

If I understand what you're saying, I think it already does.  It
looks at the class name and picks its table based on that, then looks
in the cache for the metadata.  If it's not there, it looks at the
database for the table and get the column data, then caches.  If
table not in the database, uses $this->_table_cols as a primer to
create the table, then caches.  After that it fails.  ;-)


 >> * Use of auto-increment instead of sequences (although this is a
 >> big  break from years of habit for me).
 >
 > I'd suggest trying to keep sequences around as an option.  Maybe
 > throw the nextId() type of method off to the DB which could be
 > configured to use either.
 >

Not going to get rid of sequences from the adapter, and if I can make
it swappable between autoseq/autoinc, I will.  I prefer sequences
over autoinc generally, anyway, if only from old habits.


 >> This is for a couple of reasons, the main one being that PHP
 >> doesn't  support something called "late static binding".
 >> Otherwise we'd be  able to a single Model class instead of Model/
 >> Record/RecordSet:
 >
 > Wouldn't a more proper naming convention be Model/Meta/RecordSet|
 > ModelList?  I might be a bit biased here, but it seems like the
 > Model should be the end-point, not the starting-point.  Otherwise
 > it's not really a model but a Mapper with Meta data.

I get what you're saying, but I think of that as a semantic
difference.  (Show me where "Model" is defined in PoEAA, for
example.  ;-)  A "Model" is what you point at when you say "Model",
and it can be almost anything -- although some are more useful than
others.

A TableModule with a MetadataMapper and ForeignKeyMapping and
SingleTableInheritance, with a Mapper to an ActiveRecord as the
DomainModel, seems as good as anything.

There needs to be something that collects the columns and the
relationships between the tables, and that modeling of the data
relationships is what I think of.

As far as Record/RecordSet, a Model (which models relationships in
addition to data) might well have its own Record to deal those
relationships.  With that in mind, it seems to make sense to keep the
Record with its Model, and not the other way around -- the Record is
defined by the Model it comes from.  Also, it allows for automated
fallbacks up the class hierarchy; if you extend a Model, you can
still get to its parent Record class as the default, until you need a
new extended Record as well.



--

Paul M. Jones  <http://paul-m-jones.com>

Solar: Simple Object Library and Application Repository
for PHP5.  <http://solarphp.com>

Join the Solar community wiki!  <http://solarphp.org>

Savant: The simple, elegant, and powerful solution for
templates in PHP.  <http://phpsavant.com>