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

[Travis Swicegood]

Paul M Jones wrote:
>  >> * 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.  ;-)
>   

I didn't see a setting of $this->_table_name that was working off of the 
class name.  Maybe I was looking in the wrong object.


>  >> 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.
>   

Fair enough.  I'm looking at the Model as completely storage agnostic.  
Once I get it, I could care less how it got what it needed into it 
(database, ini file, xml, php array, or smoke signals), all I want to 
know is that BlogPostModel represents a BlogPost with the a way to fetch 
the related models (BlogPostModel->comments for example, which you're 
doing), a means to grab the properties associated with it (title, body, 
created_on, etc.), and has the business logic.

Because there's so many ways to get that data into the Model, that's why 
I think it's best to keep it ignorant of the storage.  Granted, it does 
need to know what's valid and if you're using database reflection to 
figure that out on the fly, that's where a Meta object comes in.  That 
abstracts that layer out so you could replace the Meta object with 
something that's hard-coded for speed once flexibility wasn't an issue.

But you're right, it does come down to definitions (which are largely 
left to personal interpretations).  My personal one is that Models a 
collection/representation of an object within the code.  While that 
object may have a relationship to a database record for persistent 
storage, it isn't completely defined within the code as only a 
representation of that database record.  Which brings me to:

-Travis