IgnitedRecord 1.0 pre-release

[eluser]m4rw3r[/eluser]
I was not insulted or anything, just puzzled when you posted that one (if that thought crossed your mind).

I also prefer a good abstraction as long as it does not eat too much performance, or interferes with my way of thinkning/working, or if it impairs the flexibility.

That is why I have the find_by_sql() method in IgnitedRecord, some queries are just to hard to construct with PHP (or look like a complete mess in CI's AR).

EDIT. Forgot to thank for your compliments, so I'll do that now, Thanks!

[eluser]Hannes Nevalainen[/eluser]
Thanks for your reply! Now I have another question. =P (sorry if I'm bothering you).

My Files_model has a belongs_too relation with the Users_model.
When I run this code:

Code:

<?php foreach ($files as $file): ?>
    <tr>
        <td>&lt;?=$file->name?&gt;</td>
        <td>
            Size: &lt;?=number_format($file->size,0,',',' ')?&gt; kb<br />
            Uppladdad: &lt;?=$file->uploaded?&gt;<br />
            User: &lt;?=$file->get_related('user')->username?&gt;
        </td>
    </tr>
&lt;?php endforeach ?&gt;

When i run this code I end up with all these queries:

Code:

0.0008      SELECT * FROM (`files`) WHERE `is_image` = 1 ORDER BY `uploaded` desc
0.0002      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1
0.0009      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1
0.0002      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1
0.0002      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1
0.0002      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1
0.0002      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1
0.0002      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1
0.0002      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1
0.0002      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1
0.0002      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1
0.0002      SELECT * FROM (`users`) WHERE `id` = '1' LIMIT 1

Dont know if it's possible but can the record not remember that it already got user WHERE id = 1?

EDIT:

Since I has the last post I put some more in this..

It would be a nice feature if one could iterate over an IgnitedRecord with foreach like this:

Code:

foreach ($files as $file){
  foreach($file as $field){
    echo $field,'<br />';
  }
}

Right now I get some error while doing this..

Code:

A PHP Error was encountered
Severity: 4096

Message: Object of class Incidents_model could not be converted to string

Filename: controllers/incidents.php

Line Number: 13

I'm using: @version 0.1.1

Regards
//Hannes

[eluser]m4rw3r[/eluser]
No, you're not bothering me at all! I enjoy answering questions.
(and then the questions makes me question my solutions, which are good, because then I can create better code )

In the first case I guess you want to use a JOIN to get the username.
(IgnitedRecord does not do any caching for the moment, I think it should lie mostly in the db abstraction, maybe I'll implement it in a later version)

In 0.1.1 you can do it like this (but it can get messy with the columns ):

Code:

$this->db->select('files.*, users.username'); // need to select all from files
$this->db->join('users','files.users_id = users.id', 'left');
$files = $this->file->find_all(); // or something

// change
User: <?=$file->get_related('user')->username?>

// to:
User: <?=$file->username?>

In 0.2.0 (which still isn't finished) you can do this:

Code:

$this->file->join_related('user');
$files = $this->file->find_all(); // or whatever

// change
User: <?=$file->get_related('user')->username?>

// to:
User: <?=$file->user_username?>

About the iteration:

The thing is that the IR_records have a lot of properties, and not all of them are the data. Some are references to the IgnitedRecord "parent" object, others contain references to behaviours and related objects.

I "could" also create a separate "behaviour" or something that causes IR_records to implement the Iterator interface and by doing that I can implement filtering that ignores behaviours and the like (so you only receive the properties with data), but then I would make that behaviour PHP 5 only .

[eluser]Hannes Nevalainen[/eluser]
I have one more idea for your ORM, there should be a good way to create your models from the database especially to fill out the $__columns, variable.. shouldn't be that hard to implement.

[UGLY CODE WARNING]
An idea is a function that parses all php model source files and then just get the table name from $__table do a $this->db->field_data($__table); and then str_replace('var $__columns','$var $__columns',$source_file); .. a bit ugly but maybe Usefull.
[/UGLY CODE WARNING]

Another idea is to do a "model_factory" that reads YAML-files and create models from them =) That shouldn't be so much work I think. I think I'll implement one such script myself. =)

[eluser]Hannes Nevalainen[/eluser]
I have one more idea for your ORM, there should be a good way to create your models from the database especially to fill out the $__columns, variable.. shouldn't be that hard to implement.

I'cant stand the fact that it's querying the database for field metadata every time the model is constructed.. =P haha.

[UGLY CODE WARNING]
An idea is a function that parses all php model source files and then just get the table name from $__table do a $this->db->field_data($__table); and then

Code:

str_replace('var $__columns','$var $__columns = '.$generated_php_array.';',$source_file);

.. a bit ugly but maybe at least you would not have to write all your models ^^.
[/UGLY CODE WARNING]

Another idea is to do a "model_factory" that reads YAML-files and create models from them =) That shouldn't be so much work I think. I think I'll implement one such script myself. =)

EDIT: addition below

I think you should put back the primary key so one could access it like this: $user->id instead of $user->uid(), since you could always save the ID internally in the IR-object and then just ignore it if a someone tries to alter it..

It feels better to use access it like a property (an another advantage is that i don't have to change in my code =P, haha)

I understand why you have wrapped it in the uid(), but I think it would be a better approach to just ignore it onSave. (I don't know the internalls of IR but I can't imagine it would be a big brainer)

//Hannes

P.S Good to hear that I'm not annoying you ^^

[eluser]Hannes Nevalainen[/eluser]
Sorry for my misspostings..

The save() methord could take an extra paremeter (Array) containing wich fields to save =)

[eluser]m4rw3r[/eluser]
The save() method already extracts the data out of the objects before calling update or insert, the _strip_data() method takes care of this. The array to save() is not really a good idea, according to me. The right data is saved anyway because of the above.

So, IMHO this is not needed.

@everybody:
This abut the id, what does everybody else think?
I can easily make save() ignore the pk property, but do people want to have it as a property?

[eluser]m4rw3r[/eluser]
And about the file caching of metadata, maybe in a later version (I'll add it as a ticket, but is it so hard to edit by hand? The cache will get out of date sooner or later).

BTW. I've decided that before save() performs the update, the ID column will be filtered, so it will be available to the user, but not saved when modified.
This is in the latest revision (56)

[eluser]Hannes Nevalainen[/eluser]
No you are right it's not that much work (just me being lazy)..

I think it's great of you to put back the id field back. Then your view doesn't have to know it is working with an IgnitedRecord. Makes it easy to change the model in the future if needed =)

I've used your work and it's currently in production in quite big application. I once again thanks you for the great work =)

[eluser]m4rw3r[/eluser]
Thank you for all comments, and I do hope that you don't need to switch to another model

It is currently only the manual and some polishing left to do, so hopefully will version 0.2 be out soon.

Oh, and I forgot, IgnitedQuery (my SQL string builder) also needs table prefixing, which is a bit tricky to figure out how to be correct each time.
Anyone having experience of that, and might care to share?
(yes, I have read the CI code, but it does not really fit with the design of IgnitedQuery (anyone having any suggestions for a better name for that lib?))