IgnitedRecord 1.0 pre-release

[eluser]sophistry[/eluser]
i also noticed a small typo in the manual on the add_relationship() function page. the example seems to use a function called add_related() when it should be add_relationship():

Code:

$rec = $this->user->new_record();
$rec->name = 'Foo';

$rec2 = $this->post->new_record();
$rec2->text = 'This is a great post!';

$rec->add_related($rec2); // this causes both $rec and $rec2 to be saved, but not any other related objects

[eluser]dexcell[/eluser]
Hello, i would like to ask just for confirmation. Because i'm new to CI and this IR

If IR configured using the IQ, so it means it doesn't have any relation with CI AR? which means some of CI 1.7 AR bug reported doesn't have effect if i use IR.

Thanks, anyway i found some typo when i read the user guide in the svn which i download today. in performance.html which in the bottom Ignited Record written as Ignied Record

[eluser]dexcell[/eluser]
EDIT: sorry, found the problem (forgot to autoload the database when autoload IR)

I've got these 2 errors when installing rev193 to CI 1.7 fresh install
======================
A PHP Error was encountered

Severity: Notice

Message: Trying to get property of non-object

Filename: libraries/ignitedquery.php

Line Number: 140
A PHP Error was encountered

Severity: Notice

Message: Trying to get property of non-object

Filename: libraries/ignitedquery.php

Line Number: 141
=====================

[eluser]m4rw3r[/eluser]
If you use IgnitedRecord with IgnitedQuery (default), you won't have the problems that CI's AR got in 1.7.
IgnitedRecord still use CodeIgniter's AR for deletes, inserts and updates but that will be fixed when I've got time to test the delete, update and insert methods of IQ (the problems with CI's AR does not apply as much to those).
The goal is to be able to skip the usage of CI's AR completely.

Added your patch, sophistry. And it is now possible to skip the plural function in yamlfactory() (and you were wrong about not needing to load the inflector helper, the constructor is not always executed before the factory methods).
About linking tables, is it necessary with a model for them? IgnitedRecord does not need models for linking tables.

The typos you two mentioned has been fixed, thanks!

[eluser]sophistry[/eluser]
great! thanks m4rw3r.

don't linking tables need a model in order to add/edit/delete a record to/in/from them?

[eluser]m4rw3r[/eluser]
Linking tables belongs to both models: the users_groups table is used by both the user model and the group model.
So models for linking tables are not needed (it would be messy and low performing with a model for the linking table that the group and user models use).
But you can use a model if you want, but I can't see the use for it (the attributes feature covers this nicely, I think).

[eluser]sophistry[/eluser]
ok, thanks for the feedback. i'll look into the attributes feature as you suggest. :-)

[eluser]sophistry[/eluser]
just curious... why did you add the auto_pluralize parameter to the yaml factory function? i thought that models were supposed be singular forms of the table name. it doesn't make sense to me to have an already-pluralized model name that is generated by the filename of the yaml file - the model name should always be singular (according to configuration convention) and so it should always get sent to the pluralize() function. nor does it make sense to me to have a yaml file already named with the plural form because then the model would be named with the plural form. it seems that there's a point where the configuration options have to stop being options and just become conventions/patterns for developers.

i guess my question is: why would a dev ever need to set auto_pluralize to FALSE?

EDIT: also, i just looked at the attributes feature (appears undocumented at this moment) and i noticed something that should cause it not to work properly if called via the add() method. add() passes its attribute arguments on to add_relationship() but add_relationship() doesn't do anything with them!

this is not the way it should be, right? ;-) add_relationship() needs a third parameter that it passes on to establish_relationship() (which then passes it on to establish().

Code:

function add_relationship(&$object, $rel_name = false)
    {
        if(isset($this->__instance))
        {
            return $this->__instance->establish_relationship($this, $object, $rel_name);
        }
        else
        {
            IR_base::log('error','IR_record: No model is associated with the table '.
                                $this->__table);
            return false;
        }
    }

    function add($rel_name, &$object, $attributes = array())
    {
        return $this->add_relationship($object, $rel_name, $attributes);
    }

[eluser]dexcell[/eluser]
[quote author="m4rw3r" date="1225147901"]If you use IgnitedRecord with IgnitedQuery (default), you won't have the problems that CI's AR got in 1.7.
IgnitedRecord still use CodeIgniter's AR for deletes, inserts and updates but that will be fixed when I've got time to test the delete, update and insert methods of IQ (the problems with CI's AR does not apply as much to those).
The goal is to be able to skip the usage of CI's AR completely.

Added your patch, sophistry. And it is now possible to skip the plural function in yamlfactory() (and you were wrong about not needing to load the inflector helper, the constructor is not always executed before the factory methods).
About linking tables, is it necessary with a model for them? IgnitedRecord does not need models for linking tables.

The typos you two mentioned has been fixed, thanks![/quote]

Thanks m4rw3r. I've just playing with IR. Love it
I wonder is there any estimated date release of version 1

[eluser]m4rw3r[/eluser]
@sophistry
Thanks for spotting it, it is now fixed!

About the option I added to yamlfactory():
You're right, I'll just revert to your patch, as always I let the developer choose to much.
(maybe I should have hardcoded my ORM to use a table called "foo" for everything, it would have been so much easier for all who use IR )

@all:
It isn't easy to guesstimate a date, but according to the tickets, it isn't too much left.
But then I have to rewrite some (most?) parts of the manual (btw, anyone who wants to help with that?), redo speed tests (I think I got it about 15% faster ) and then do some general polishing.