CodeIgniter Forums
IgnitedRecord 1.0 pre-release - Printable Version

+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived Libraries & Helpers (https://forum.codeigniter.com/forumdisplay.php?fid=22)
+--- Thread: IgnitedRecord 1.0 pre-release (/showthread.php?tid=7996)



IgnitedRecord 1.0 pre-release - El Forum - 09-16-2008

[eluser]Heli[/eluser]
thanks


IgnitedRecord 1.0 pre-release - El Forum - 09-18-2008

[eluser]m4rw3r[/eluser]
Another update:

I'm refactoring some code in IgnitedQuery which hopefully will improve performance and usability.

One thing I'm working on is to decouple the subquery objects and the "main" query object, so it is possible to reuse the subquery in many "main" queries and/or through AR caching:
Code:
// here is a through relation, which I'll start implementing soon
$sub = new Query();
$sub->select('user_id')->from('groups_users')->where('group_id', 1);

// use first time:
$this->post->where_in('user_id', $sub)->find_all();

// now we want a count
$this->post->where_in('user_id', $sub)->count();
So this makes it possible to reuse subqueries, and I'll also add a cache for the query string, so the subqueries are only created once (unless they are changed).

I have also decided to rename version 0.2.1 to 1.0.0, to indicate that it is more stable.

And if that wasn't enough, I'm still open for suggestions, as always. Smile


IgnitedRecord 1.0 pre-release - El Forum - 09-19-2008

[eluser]gungbao[/eluser]
Quote:And if that wasn’t enough, I’m still open for suggestions, as always


please please please... a php5only standalone version to include it in ANY existing php software.
I have don this with your 0.1 version but arrrgghhhh overwrote it today on my non-svn machine with your 0.2 branch and cannot get it working again Sad

this would be the killer thing for any PHP developer Smile


IgnitedRecord 1.0 pre-release - El Forum - 09-20-2008

[eluser]gungbao[/eluser]
@m4rw3r
great work and reads fantastic, but your current 0.2.0 version makes me headaches when it comes to ->related('bla'). I cannot even get your examples running (same error as posted from other user Unknown column 'group_id' in 'field list').

so i wanted to checkout your current svn version, sorry to ask, is this possible - because tortoise asks me for login an password Sad

big thanks, i am eager to work with that lib.
Cheers, Chris


IgnitedRecord 1.0 pre-release - El Forum - 09-20-2008

[eluser]m4rw3r[/eluser]
Well, the idea of making a standalone version have crossed my mind, and I must say that I'm definitely not against it.
I'm going to move a lot of the CI specific functions (log_message(), etc.) to static methods in IR_base, which will make porting it a lot simpler.

The hardest part with making a stand alone version is the db abstraction, IgnitedRecord is still using some of CI's ActiveRecord.
IgnitedQuery is constantly getting better, but I need to finish and test the insert/update/delete methods.
And IgnitedQuery depends on the standard db abstraction, so that has to be ported too (or replaced).

@svn:
It should work without username and password, they should only be needed if you want to be able to commit.


IgnitedRecord 1.0 pre-release - El Forum - 09-21-2008

[eluser]sophistry[/eluser]
@m4rw3r... first, thanks for making such a cool and comprehensive ORM for CI - it has that same feeling that CI does that it seems to adroitly anticipate my next need at every turn.

i'm attempting to use the yaml helper and i have two questions (related to each other) and a request.

why is the table setting necessary if the db schema follows the default convention of being the plural of the model name? shouldn't the yaml helper be able to get the table name based on the yaml filename? just my first thought (as a lazy programmer who doesn't want to type an extra 30 chars). also, shouldn't the related table be detectable by the yaml helper too? see below where the habtm setting is defined as groups, but then the yaml file shows the join_table explicitly defined even though it fits the default conventions.

and, could you please post two or three examples of how to use yaml files in defining models. i have a fairly complex db schema and i'd love to have something to work from! especially, i'd like to know if the yaml helper can successfully implement all of the default conventions for data relationships. if not all, then which ones?

i was able to get the models to load using the example in the docs, but it leaves out some stuff:

in my controller constructor:
Code:
$this->user = IgnitedRecord::yamlfactory(APPPATH.'definitions/user.yaml');

and the yaml file:
Code:
table: users
habtm:
    name: groups
    join_table: groups_users

for instance, shouldn't this habtm relationship be the only thing that needs to be defined (along with the filename that expresses the main table name)

thanks!


IgnitedRecord 1.0 pre-release - El Forum - 09-21-2008

[eluser]m4rw3r[/eluser]
I can agree that it seems unnecessary to write the tablename in the YAML, but I have made yamlfactory() able to create it from string input (eg. db input) and files.
I'll make it fetch the tablename from the filename if it isn't defined (tablename = filename).

In the YAML you define it as you would define it in the class definition, so you can use the advanced mode or the "simple" mode when defining relations.
So the YAML should be capable of doing everything you can do with the class definition.
The example was just an example, to proof that the advanced variant can be used.

Here is some more example YAML:
Code:
# YAML file ./application/definitions/users.yaml
id_col: pk
habtm: groups
has_many: [posts, images, comments]  # = array('posts', 'images', 'comments')
has_one: avatar    # now links to avatars, as usual conventions

# YAML file ./application/definitions/groups.yaml
habtm: users
has_many:
    - name: posts
      through: users     # going to implement this soon
    - name: images
      through: users

Thanks for the compliments!


IgnitedRecord 1.0 pre-release - El Forum - 09-21-2008

[eluser]sophistry[/eluser]
wow... super fast reply!

so, i see from your example and from my own testing that you *can* (maybe?) leave out the join_table setting for habtm setting and the system determines it by default. but, i tried that and it didn't seem to work. i might have something else wrong though...

i am trying to take the quick start HABTM set up (with slightly different table names) and convert it to use yaml. so, i know the datamodels, data, and code have all worked before!

here's my yaml factory instance code:
Code:
// define the two models in constructor
// (not defining a yaml-driven model for join
// table beings_groups because i didn't have
// to before i started using yaml)
$this->being = IgnitedRecord::yamlfactory(APPPATH.'definitions/being.yaml');
$this->group = IgnitedRecord::yamlfactory(APPPATH.'definitions/group.yaml');

my call to find() (which works) and the subsequent $rec1->related():
Code:
$rec1 = $this->being->find(1);
echo 'being '. $rec1->first_name .' belongs to groups:<br>';
$related_recs = $rec1->related('groups');
foreach($related_recs as $r)
{
     print_r($r->group_name.'<br>');
}

and my yaml:
Code:
table: beings    # necessary
habtm:
    name: groups

the print_r() says "Message: Undefined property: group_name" but there is a field in the groups table. and the data is there.

do you see any problems with this?

on another note
---------------
as you say IR has these two modes:

1) simple: default settings and minimal configuration as long as you follow conventions
2) advanced: all settings can be specified away from the default conventions for the ultimate flexibility with existing db installations

since i am not completely fluent in IR, it is sometimes hard for me (and other new users i'm sure) to know exactly which settings are option for the various techniques of model instantiation (extend IR, factory, yamlfactory). as a general suggestion for examples, could you try to be a little more verbose when you comment those things?

another final thing... is it possible to load just one yaml file that holds all the definitions? my schema has about a dozen tables and i'd like to be able to just have them all in one single file. i know i can write a wrapper function and just parse them out myself, but i wonder if that capability is already in the system somewhere, undocumented? if it's not, i'd be happy to accept guidelines for development and contribute such an item when i get it working. :-)

thanks!


IgnitedRecord 1.0 pre-release - El Forum - 09-21-2008

[eluser]m4rw3r[/eluser]
The related() method returns a IR_RelQuery object, which is used to manipulate and execute the query.
You have to call get() on the object you receive from related() to fetch the related records.

Code:
$rec1 = $this->being->find(1);
echo 'being '. $rec1->first_name .' belongs to groups:<br>';
$related_recs = $rec1->related('groups');
// here you can place calls which manipulate the query, example: $related_recs->order_by('title', 'desc');
foreach($related_recs->get() as $r) // call get(), fetching the groups
{
     print_r($r->group_name.'<br>');
}

The yamlfactory() is currently not able to load multiple models from the same yaml file, because the model name must then be determined and then multiple models must be returned in a nice way.
It is certainly possible to do it, and here is a hint (I just threw it together):
Code:
function yamlfactory($yaml_str)
{
    $array = yayparser($yaml_str);
    $ret = array();  // dunno if this is the best return variant
    foreach($array as $table => $settings)
    {
        $ret[$table] =& IgnitedRecord::factory($table, $settings);
    }
    return $ret;
}

EDIT: The yaml for the function above would look similar to this:
Code:
users:
    id_col: pk
    has_many: posts
    habtm: groups
groups:
    habtm: users
    has_one: description # not needed, but just to show
descriptions:
    belongs_to: group



IgnitedRecord 1.0 pre-release - El Forum - 09-21-2008

[eluser]sophistry[/eluser]
ok, i knew i was missing something! i even had the manual page open to that spot... but, because i had worked with an earlier version of IR i assumed that even though the function name changed that the thing still worked the same - my bad.

now that i have the function working, i realize that with the sub-selects in the related function, i have to upgrade my legacy mysql install - running old v4 still. the old IR worked with it, but this new version doesn't.

doh!

thanks for the swift help.