IgnitedRecord 1.0 pre-release

[eluser]Burgestrand[/eluser]
--[ Question rewritten (using version 1.0, btw):

I’ve written a convenience method (helper):

Code:

/**
     * Returnerar user-objektet, eller ett tomt objekt med samma attribut :o
     *
     * @return IR_Record models/Users.php OR config/schema.yml för att få listan över attributen
     */
    function get_user()
    {
        if ( ! $user = authenticated(TRUE))
        {
            // Vi är inte inloggade, så skapa en ny “tom” användare
            $users = new Users();
            $user = $users->new_record(array_combine($users->list_fields(), array_fill(0, count($users->list_fields()), NULL)));
        }
        
        return $user;
    }

The general thought is this: get_user() returns a record from the Users table. If the current visitor is logged in their record is returned, otherwise an empty (all columns set to NULL) is returned. Is there a prettier way of constructing this record?

Secondly I'd like to make a suggestion in “base.php” and “base_php5.php” @ line 108:
from:

Code:

function list_fields($table)
{
        $model =& IR_base::get_model($table);
        […]

to:

Code:

function list_fields($table = NULL)
{
        (is_null($table) AND $table = $this->table);
        $model =& IR_base::get_model($table);
        […]

This would allow one to ommit the table name (as I’ve done in my helper above).

Finally a quick question (possible bug) in ignitedquery.php in method delete (line 1751 -> 1759):

Code:

if(empty($this->q_where) && empty($this->like))
        {
            return false;
        }
        
        if($where != NULL)
        {
            $this->where($where);
        }

Shouldn’t the latter if-statement preceed the former? Also, the method itself doesn’t take notice of the db_prefix set in the CI database config. I hit this problem when running the following code:

Code:

$posts = new Posts();
                    if ($post = $posts->where('author', $user->username)->find($id))
                    {
                        $post->delete($post); // this line *is* run, but nothing is deleted
                    }

[eluser]m4rw3r[/eluser]
@r2b2_kvr:

yes, they are both there in the svn (although the form generation isn't so good as I would like to have it) - but missing some doc.

@Burgestrand:

(ser att du är svensk )
You shouldn't really instantiate the model yourself unless you know what you're doing.
Fetch it instead from the CI superobject.

And why do you need an empty object populated with zeroes?
Because the user model returns false if it cannot find a record.

Nice addition to the base! Going to add it.
Also going to take a look at IgnitedQuery.

EDIT: The SVN already had that fix for the delete() method

[eluser]Burgestrand[/eluser]
[quote author="m4rw3r" date="1240875229"]You shouldn't really instantiate the model yourself unless you know what you're doing.
Fetch it instead from the CI superobject.[/quote]
Whoops! Good point!

[quote author="m4rw3r" date="1240875229"]And why do you need an empty object populated with zeroes?
Because the user model returns false if it cannot find a record.[/quote]
It’s more of a convenience method that’ll always return a user record (regardless if the current visitor is logged in or not). This way I can avoid doing checks if the user exists every time I need to access its' properties (which is what the authenticated() method does).

Say… for example I have this view partial:

Code:

<form action="<?=site_url('forum/post')?>" method="post" accept-charset="utf-8" class="post">
    <fieldset>
        <legend>Nytt inlägg</legend>
        <ul>
            <li><label>Namn: &lt;input type="text" name="author" size="21" maxlength="50" class="required" title="Namn" value="&lt;?=get_user()-&gt;username?&gt;" &lt;?=authenticated() ? 'readonly="readonly"' : '')?&gt;></label></li>
            <li><label>E-Mail (valfritt): &lt;input type="text" name="email" size="21" maxlength="320" title="E-Mail (valfritt)" value="&lt;?=get_user()-&gt;email?&gt;"></label></li>
            <li class="message"><label>Meddelande: &lt;textarea name="message" class="required" rows="5" cols="20" title="Meddelande"&gt;&lt;/textarea></label></li>
            <li>
                Vill du ha snyggare inlägg? Läs <a href="&lt;?=site_url('forum/markdown')?&gt;">stilguiden</a>!
                
                &lt;input type="submit" value="Skicka inlägg"&gt;
                
                &lt;?php $this->load->view('partial/form/hidden_fields') ?&gt;
            </li>
        </ul>
    </fieldset>
&lt;/form&gt;

I can use the property directly (“get_user()->username”) instead of doing (“authenticated() ? get_user()->username : ''”). Setting the column values to NULL when there's no record seemed logical to me, so I was wondering if I were missing something.

[eluser]m4rw3r[/eluser]
Why not do something like this:

Code:

// always return an empty string ;)
class Fake_user{
    function __get($key)
    {
        return '';
    }
}

if( ! $user = $this->user->find(...))
{
    $user = new Fake_user();
}

[eluser]Burgestrand[/eluser]
Three reasons!

First off it throws an error (it doesn't like assigning by reference in base_php5.php:54) if I do this. Easily patched around by defining the class variable “$db” in the class, though.

Secondly I’d have to do this for every model that would use this functionality (which means all ). Not a big issue, except it’d hide programming errors during coding (say I misspell a property name D: !).

And finally it would not have the same methods as the IR_record class, which is half the point of why I’m doing it! No “is_db” and so on.

PS: I would not want to assign an empty string to all columns by default as NULL is the absence of value where an empty string is a value. So… NULL, not ""

[eluser]Tim Stackhouse[/eluser]
[quote author="m4rw3r" date="1226684771"]Fixed that error, Belongs To relations didn't have a plural property but now they do .[/quote]

Sorry if this has already been answered, but is this fixed in the current release? I'm running 1.0-pre (r218) and I'm still getting the plural property error. Any help is greatly appreciated.

Edit: Nevermind, I pulled the latest from SVN and all seems well.

[eluser]Tim Stackhouse[/eluser]
@Burgestrand: Why not instantiate a new record (i.e. $user = $this->user->new_record()) and than just never save()ing it and overwriting it when a user logs in?

[eluser]Tim Stackhouse[/eluser]
Am I doing this wrong?

I have 2 HABTM objects, Users and Roles. I want a list of roles NOT assigned to a given user and I'm using the below code:

Code:

$this->Role->join_related('users');
$roles = $this->Role->find_all_by('user_id !=', $id);

But it's doing the opposite! I'm not sure what I'm doing wrong here...

Edit: I was hoping to do this without touching SQL, but this did it:

Code:

$roles = $this->Role->find_all_by_sql('SELECT roles.* FROM roles WHERE roles.id NOT IN (SELECT role_id FROM users_roles WHERE user_id = ' . $id . ')');

I'm two-for-two, I should take some more time to try and figure things out before posting to the forums for advice...

[eluser]Tim Stackhouse[/eluser]
[quote author="m4rw3r" date="1227329253"]About "real" cascading deletes:

Because I've abandoned CI's AR, it is done now!
(actually very fun to code, with IgnitedQuery's subqueries and a sort-of recursion)

So now IgnitedRecord performs real cascades through a whole relation tree. ...[/quote]

So IR performs proper cascading deletes, it's a wonderful feature, however It's now ignoring the cascades in my DB. I've found the "'cascade_on_delete' => true" option earlier in this thread, however I'd like to have my DB handle all my cascades, specifically since I have a couple ON DELETE RESTRICT relationships set up that IR is bypassing. Is there some setting to turn off cascading across my entire app?

[eluser]m4rw3r[/eluser]
Well, your first problem (that you solved) can also be done with IgnitedQuery too (subqueries )

Your second question:
If the cascade_on_delete isn't set to true, it won't cascade at all - and that is the default behaviour (I encourage the usage of database cascades, as they can handle more elaborate cases).
If the cascade doesn't take place, IR will NULL the foreign key in the related records so they are clearly not belonging to anything.