Welcome Guest, Not a member yet? Register   Sign In
IgnitedRecord 1.0 pre-release

[eluser]Paul Apostol[/eluser]
I have 3 tables: firms, departments, employees (firms has many depts, depts and employees are habtm). Chained relations are supported?
As ex:
foreach ($employees->find_all() as $val){
$departments =& $val->related('departmets');
    foreach($departments->get() as $dept)
        $firm = &$dept->related('firm');
        echo $firm->get()->name;


I am curious about the following scenario:

I have a map table for a many to many relationship that has more then just the FK fields. How do I access that additional data? example(foo_id, bar_id, additional_data).

in addition: when trying to load related records, the following error:

A Database Error Occurred

Error Number: 1064

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use nearSELECT * WHERE `id` IN ('203', ...

The list in the parens is way too long so no filtering is happening.

class food extends IgnitedRecord
         var $belongs_to = 'foodgroup';
         var $has_many = 'weights';
         var $habtm = 'nutrients';
class nutrient extends IgnitedRecord
        var $habtm = 'foods';

in controller constructor:


$food =& $this->food->find($_POST['foods']);
                $nut =& $food->related('nutrients');
                $data['noots'] = '<strong>'.$food->id.' - '.$food->frndly_name.'</strong><br/ >';
                foreach($nut->get() as $nutrient)
                    $data['noots'] .= $nutrient->id.' - '.$nutrient->name.' - in: '.$nutrient->units.'<br />';

What am I doing wrong?


Thanks m4rw3r. This is a good strategy.

I have to say I'm getting a lot of good use out of IR. It has enough functionality to allow me to do common stuff very quickly and enough flexibility to allow me to do more complicated things that I can't easily do in other ORM solutions. Good work.

Also, I wrote a sluggable (or maybe it should be called slugged?) model behavior to create URL slugs based on a model field of your choosing. What is the best way to make it available to others?

[eluser]Paul Apostol[/eluser]
No answer to my post.
No problem, but, please, at least make a complete and updated manual to this library before you start to build the new one.
Or do you plan to drop it? (no final release?)
Thank you,

@paul Apostol:
Yes, chained relations are supported, but in your case (and many others) I suggest using join_related() instead of IR_record::related().

foreach($this->employee->find_all() as $emp)
    foreach($emp->departments as $dep)
        echo $dep->related('firm')->get()->name;
Only n + 1 queries compared to n * m + 1 queries (which is a great difference).

I'm not really sure if I should continue with IgnitedRecord in its current state.
Ci's Db abstraction steals quite a lot of performance, especially when creating custom objects (but PDO is even slower at that, haha), so I'm currently experimenting with a rewrite (PHP 5?, I dunno) of CI's db abstraction. This would also require a rewrite of IR.
It is currently also standalone, not only CI compatible, and its performance is 20-40% better than CI's, and it is not as bloated (better OOP, hence maybe PHP 5 only).
Furthermore, I can make it handle multiple db instances and also easier to access from the whole part of the PHP script.

Also, I'm soon starting my last year at my school, and I need to do something as an exam job (at least 100h). So I think that working on a rewrite of IR from scratch with a complete db abstraction would be a good thing to do, because I can involve some things from maths, english, programming etc. (It must be related to some school stuff).
We cannot start on the exam jobs yet (will start in 11 weeks), I may be able to start earlier, which would be within a few weeks.
I need to check who's going to have the rights to the source code, too (because I want to be able to call it MINE Tongue)

I wonder: Should I make the manual and then try to continue on IR as is, or is a rewrite better? (I lean towards a rewrite, because of the benefits for both me and performance)

here'e what i think:

1) go php5 all around; it's the future
2) make sure you own your stuff; don't give away the rights to some faceless bureaucracy
3) speed is better than docs - especially if it makes you happy
4) docs are good if you have a solid release that you are willing to fix and update even as you follow the next thing over the horizon, but there is no point documenting a moving target.

that said, i've been following (and will continue to follow) the development of your library. i am impressed with your alacrity and adroitness, but the moving target aspect has made it difficult for me to commit to it long term. also, as i've said, i'm happy to help "flesh out" the manual when and if it gets a skeleton!


[eluser]Paul Apostol[/eluser]
Thank you for your answer. I want to use "join_related" but it gives me an error and the sql shown has in the second join in "ON" clause at the first table the name of the table and not the name of the alias.
The first error was because in a BT->HM relation I used foreach but with what I read here I understood how it's working.

As a personal opinion for a framework the speed is not the main target, is the second (even if I like a fast framework). It has to deliver functionality.

Good luck with your school, is surely more important for your life than this library.


Hi all,

(Sorry for the double post)

I’m trying to add multiple objects as relations via IR, thusly:

/* New record from data */
    $this->rec = $this->{$this->name}->new_record($data);

        foreach($images as $k=>$v) {
                /* Get related images */
                $rel[$k] = $this->image->find($v);
                /* Add relation */
                $this->rec->add_relationship($rel[$k], 'images');

However, only the last object ever gets added to the relations table. I take it I’m doing this completely wrong?


What kind of relation is it?
Because Has One automatically removes any existing relations when a new is assigned (does NOT delete the related data, though).

Theme © iAndrew 2016 - Forum software by © MyBB