IgnitedRecord 1.0 pre-release

[eluser]m4rw3r[/eluser]
Hi again!

Due to messy validation and very repetitious code when doing creations/edits of records in a project, I've started to make a validation behaviour for IgnitedRecord.

It will have precedence over the through relationship type, so after I'm finished with the validation behaviour I'll start on that.

So the question is: What do you want to have in a good model validation addon?

[eluser]Paul Mastin[/eluser]
Hi,

To start, great library, I have been looking for something like this for some time. I think it elegantly mimics the Ruby on Rails approach to the problem of ORM within the constructs of PHP.

I have been going through the documentation, and I must say, again, nice work on having good documentation. A thought that I wanted to contribute was this: a significant portion of the terminology in the documentation is very similar, many terms are quite similar, and sometimes can run together. An example of this is when speaking about tables that store relational data. The terminology is almost identical, thus making it a bit confusing while attempting to learn the ins and outs of the library.

All in all, this is on its way to being a fantastic library, and in my opinion, one of the distinguishing factors between a library well done, and an excellent piece of work is the documentation.

Paul

[eluser]m4rw3r[/eluser]
@paul:
Thanks for the appreciation, I'll take a thorough look at the manual before I release version 1.0.0!

@all:
News:
I'm also working on a form generation utility, integrated with the validation. It seems to be working well, but currently there are no view file or manual for it.
So if you have any suggestions, post!

[eluser]m4rw3r[/eluser]
A new feature: Object splitting with JOINs

It is now possible to join Has Many and Has And Belongs To Many relationships with the query, to reduce the number of queries to 1 instead of 1 + n (where n = the number of records in the first table).

Another thing this does is making it possible to get the objects of the related records without making an additional query or some code to extract data from the fetched object.

Example:

Code:

$this->thread->has_many('posts');

$this->thread->join_related('posts');
$threads = $this->thread->find_all();

foreach($threads as $t)
{
    echo $t->name;
    echo $t->date;
    echo 'Posts:';

    foreach($t->posts as $p)
    {
        $p->body;
    }
}

The code above only makes one query, which will make a great performance improvement (over 200% faster with small recordsets, a lot larger with large recordsets).
A thing not currently possible in the case above is to join the username of the posts, but that will work when I'm finished with the Through relationship type.

Another example:

Code:

$thread = $this->thread->join_related('user')->find(1);
$thread->user->username = 'Fool'; // just to prove that $thread->user is a record object
$thread->user->save(); // saves the user object

BTW, with the changes to dbobj2ORM(), IgnitedRecord is also ~4% faster when making ordinary queries (SELECT * FROM `table`).

[eluser]MarcoITA[/eluser]
Another small issue.

When trying to create 2 relations to the same table the SQL query does not use aliases for the tables, creating SQL error.

Example with two 'belongs_to' relations to the same 'users' table via different fks: default ('user_id') & 'ultimoagg_user_id'

Model:

Code:

class Content extends IgnitedRecord {

    var $habtm = array(
        'pages' => array(
            'name'          => 'pages',
            'join_table'    => 'blocks',
            'attr'          => array('zona','posizione'),
        )

    );

    var $belongs_to = array(
        'user',

        'ultimoagg_user' => array(
            'table' => 'users',
            'name'  => 'ultimoagg_user',
            'fk'    => 'ultimoagg_user_id',
        ),
    );

SQL generated:

Code:

SELECT
  portal_blocks.zona,
  portal_blocks.posizione,
  portal_users.id AS user_id,
  portal_users.login AS user_login,
  portal_users.password AS user_password,
  portal_users.nome AS user_nome,
  portal_users.email AS user_email,
  portal_users.id AS ultimoagg_user_id,
  portal_users.login AS ultimoagg_user_login,
  portal_users.password AS ultimoagg_user_password,
  portal_users.nome AS ultimoagg_user_nome,
  portal_users.email AS ultimoagg_user_email,
  portal_contents.*

FROM
(`portal_contents`)
JOIN
`portal_blocks`
  ON portal_blocks.content_id = portal_contents.id
LEFT JOIN
  `portal_users`
  ON portal_contents.user_id = portal_users.id
LEFT JOIN
  `portal_users`
  ON portal_contents.ultimoagg_user_id = portal_users.id
WHERE
  portal_blocks.page_id = '1'
ORDER BY
  zona, posizione

this give SQL Error Number 1066: Not unique table/alias: 'portal_users'

SQL should use relations' defined name as aliases for related tables' joins:

Code:

SELECT
  portal_blocks.zona,
  portal_blocks.posizione,
  user.id AS user_id,
  user.login AS user_login,
  user.password AS user_password,
  user.nome AS user_nome,
  user.email AS user_email,
  ultimoagg_user.id AS ultimoagg_user_id,
  ultimoagg_user.login AS ultimoagg_user_login,
  ultimoagg_user.password AS ultimoagg_user_password,
  ultimoagg_user.nome AS ultimoagg_user_nome,
  ultimoagg_user.email AS ultimoagg_user_email,
  portal_contents.*

FROM
(`portal_contents`)
JOIN
`portal_blocks`  
  ON portal_blocks.content_id = portal_contents.id
LEFT JOIN
  `portal_users` as user
  ON portal_contents.user_id = user.id
LEFT JOIN
  `portal_users` as ultimoagg_user
  ON portal_contents.ultimoagg_user_id = ultimoagg_user.id
WHERE
  portal_blocks.page_id = '1'
ORDER BY
  zona, posizione

[eluser]m4rw3r[/eluser]
A good suggestion, I'll get right on it!

[eluser]MarcoITA[/eluser]
Good! Please post here when it will be implemented in trunk SVN... I'm working on other parts of my script awaiting this from you

PS: 2 days ago I updated to the last SVN (maybe 183?) but then reverted back due to "related" method not found in class?!?!

Was it a transitional "error" or are you changing things?

[eluser]m4rw3r[/eluser]
I've now added the "smart" table aliasing. It aliases the table if the table name is differing from the relation name (when fetching related).

I've also improved IgnitedQuery so it is still a few percent faster than CI's AR as SQL builder (used some neat tricks I saw in CI 1.7 + fixed a few bugs to avoid unnecessary loops).

The error with the related() method not found, was this when using IR methods which should return a single record?
If yes, that has been fixed (it was a transitional error of sorts, remnants from before the refactoring of dbobj2ORM()).

[eluser]m4rw3r[/eluser]
Note to you all using SVN:
The IgnitedRecord files has been moved to: http://svn.assembla.com/svn/IgnitedRecor...itedrecord

It makes more sense to put a library in the libraries dir

[eluser]sophistry[/eluser]
m4r... nice work. it looks like lots of cool new stuff in there. it's humbling to see that you've actually put some of our suggestions into this library. hopefully, it's made it better. i recently got PHP5 so i'll be testing some of the other features that weren't available to PHP4.

thanks for your hard work in this area. IMHO, your ORM library is currently the premier solution for CI devs who want to manage a large multi-table database with as much automation as possible.

:-)