[Solar-talk] some thoughts about models

[Paul M Jones]

Hi Stefan,

> i was looking in the new model implementtion and i felt like doing  
> some comments.
> As far as i understand Models are an Active Record + Table Getway  
> implementation in Solar.

Yes, that's very close -- to be more specific:

* the Model class ~= TableModule (i.e., TableDataGateway + DataMapper  
+ logic)

* the Record class ~= ActiveRecord (i.e., RowDataGateway + DataMapper  
+ logic)

* the Collection class ~= RecordSet

As far as these requirements, they are already completed:

> Table design can be different, but for most application in a table  
> we should have :
> - date created
> - date last update
> - table_id ( could be autoincrement like in mysql, informix or  
> mssql or sequence like in postgres or oracle).
> - other fileds

In the model class, see the properties "_created_col",  
"_updated_col", and "_primary_col".  Primary (ID) key is read from  
the table and automatically set by the database.  (Solar SQL  
recognizes Sqlite "AUTO INCREMENT PRIMARY KEY", PostgreSQL NEXTVAL()  
default, and MySQL auto-increment ... and will recognize MS-SQL and  
Oracle versions as well.)


> First i would like to start with INSERT method, describing my  
> opinion. :
> - table_id should not be a part of inserted fields; if the table_id  
> (not necesary primary key) is a sequence

What insertRecord() currently does is look to see if the ID is there;  
if so, it leaves that ID alone.  If null, it lets the database  
populate that value, then retrieves it after insert.


> we should use default value (in postgres) or triggers (in oracle)  
> to insert that value.

Solar_Sql_Adapter classes do this for PostgreSQL, and are *planned*  
to do that for Oracle when we get it back in the system.  (And yes,  
we *are* going to have Oracle support at last.  ;-)


> so the insert statement should look like :
>    insert into TABLE (date_created,field1,field2) values  
> (now,value1,value2);

> - date values should be from the database server, not from the  
> apache + php server

Doing this now, with one caveat: we use the database DATE/TIME/ 
TIMESTAMP type, but force the connection to auto-format them to  
ISO-8601 standards.


> - if a field is missing we should automatically assign the default  
> value or exclude them from insert.

Doing this now.


> The UPDATE method :
> - don't update a field if the value is not changed

That one's a little harder, but it *is* planned.


> - select the record first and if the 'last update' field's value is  
> different from updated record do not make the insert,

That is ... optimistic locking?  (Or pessimistic? I can never  
remember. ;-)  That's a good idea, I'll see if I can include it in a  
future version.  Can you open an enhancement request for that at  
<http://solarphp.com/trac> ?


> what do you think?

I think they're all good ideas, and mostly completed already.

Hope that helps, please let me know if it does not.




--

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>