IgnitedRecord 1.0 pre-release

[eluser]roguewave[/eluser]
I'm certainly no Ruby expert so I'll can't comment on that. And I didn't think of the PHP 4 compat issue. That in itself would be reason enough that the "straight" conversion cannot be done.

[eluser]louis w[/eluser]
Any intention on adding relations information to the manual. This is a feature i am very interested in learning more about.

Also, the manual on the assembla site is jacked up. The entire column is displaying about 100px wide, making it very hard to read (FF and Safari on Mac).

[eluser]m4rw3r[/eluser]
I'm currently beginning on it.

I've also fixed the manual (at least somewhat), it got messed up when I reverted the assembla css to defaults.

[eluser]m4rw3r[/eluser]
IgnitedRecord version 0.2.0 is finished!

It is now finally finished! (But I guess you have suggestions for improvements )

Here is the complete change log for version 0.1.1 -> 0.2.0 : (Ugh, it's loooong)

* Rewrote most of the relation code to...
    o Make it more compact and more efficient
    o Correct the bug when IgnitedRecord cannot find the model of a related table (because it was not existing in the constructor)
    o Enable sorting and filtering (and extreme customization :-) ) when fetching related records
    o Make it easier to mantain for me
    o Note: The foreign column names now default to {singular}_id instead of {plural}_id
    o Note: The column term have been replaced with foreign_key, shorted to fk
    o Note: The foreign_column term have been replaced with related_foreign_key, shorted to related_fk
    o Note: The rel_table term have been replaced with join_table
* Note: All properties of the IgnitedRecord class are no longer prefixed by double underscores!
* Added has_many(), has_one(), belongs_to() and habtm() which specifies the settings for relations through IR_RelProperty objects
* Removed set_belongs_to(), set_has_many(), set_has_one() and set_habtm() in favor of those above
* Added the abillity to join related records into the currently forming query (only Has One and Belongs To, requires IgnitedQuery)
* The property $__auto_load_relationships has been removed
* Added act_as(), which can load behaviours on the fly
* Added child_class(), which can set the class name, of the objects to create, on the fly
* Added support for completely working serialization of IR_records (added __sleep() and __wakeup())
* establish_relationship() (and add() + add_relationship()) now returns true/false depending on if it really was saved
* Added hooks in _dbobj2ORM() which enables the hooked code to add / modify the IR_record object before / after their creation
* Removed get_related() from IR_Record
* The unique identifier can now be handled as a property, but it won't be saved on UPDATEs
* IgnitedRecord has now got it's own SQL string builder for the get-type queries (IgnitedQuery), optional
* IgnitedRecord does no longer load the needed models, all models need to be loaded by the user
* SQL string generation methods can now be accessed directly from IgnitedRecord
* Behaviours can now abort save(), update() and delete()
* IgnitedRecord does no longer extend the model class
* IgnitedRecord_record has been renamed to IR_record
* Moved the "helper" classes out of ignitedrecord.php into their own files
* Rewrote the manual
* Removed the Change Log from ignitedrecord.php, just waste of space having it in two places

The new relation code is the greatest difference from version 0.1.1, it is almost not restricting at all what you query for when fetching related records (well, the condition to meet is that they are related ).

The second greatest difference is the new SQL-query builder, which supports more advanced queries than ActiveRecord (not enabled by default, and can be used as a stand alone SQL-builder).

I appreciate suggestions and comments (and behaviours), as always

[eluser]stensi[/eluser]
Nice work :-) Good to see the new features in there!

Sorry to say but I've run into some problems while running your <u>Quick Start</u> instructions. Following just those instructions, I get this error:

Code:

user with id #1: me
user me belongs to groups:

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 near 'WHERE `id` IN ('1', '1', '2', '2')' at line 2

SELECT * WHERE `id` IN ('1', '1', '2', '2')

Since I prefer to use the "_model" suffix, I'll continue testing with a User_model and Group_model and let you know how I go. For starters, I found this bug:

<b>application/models/ignitedrecord/ignitedrecord.php</b>

On line 1397 (in load_has_one function) replace:

Code:

$rel_query->where($data->column(), $obj->__id);

With:

Code:

$rel_query->where($data->get_fk(), $obj->__id);

Does IgnitedRecord now automatically load the Group_model if it exists? The <u>Quick Start</u> instructions don't mention having to make it but after I did, I got different results?

<b>UPDATE:</b>
I've got my <u>has_many</u> / <u>belongs_to</u> and <u>has_one</u> / <u>belongs_to</u> relationships working perfectly now in regards to getting related records.

Scenario:
A group can have many users but a user can belong to only one group. For this situation, I have tested with the <i>group</i> model having the <u>has_many</u>, and the <i>user</i> model having the <u>belongs_to</u>. The user table has an additional column added to it called "group_id". Is this how you would have done it?

I'm still having issues with the <u>habtm</u> / <u>habtm</u> relationship. I'm currently getting errors like this:

Code:

A Database Error Occurred

Error Number: 1052

Column 'group_id' in where clause is ambiguous

SELECT `user_id` FROM (`users`, `groups_users`) WHERE `group_id` = '1'

I'm attempting to get related records in a similar way to that described in the <u>Quick Start</u> instructions, but have swapped group and users so i get a group then the related users for that group.

How are you meant to get related records for habtm relationships? Note that I'm not using IgnitedQuery.

[eluser]m4rw3r[/eluser]
Well, I haven't got so much time right now, but I will answer as much as I can now, and then the rest when I have time.

The bug with the lack of a table name, I'll look at it (load_habtm() should add one, strange...).

Thanks for spotting that typo, I'll correct it as soon as possible.

* IgnitedRecord does no longer load the needed models, all models need to be loaded by the user

So yes, you have to load the related models (I'll make it more clear in the manual).
But in the quick start, there are only read queries, so it doesn't matter there (The result should be the same, but you should be able to edit and save the related records if you have the related model loaded).

The error with the HABTM request is probably because you have a group_id column in the users table, and MySQL cannot figure out which of them to match. So the solution is to remove the group_id from users (Maybe I'll take a look at prefixing it with table names).

[eluser]m4rw3r[/eluser]
The habtm error you described (probably both), I've nailed down the problem.

The problem is (or was, it is fixed in SVN revision 102) that there is interference between two queries in the load_habtm() method (because the nature of CI's AR), hence the two tables in the query.
(Or, you can use IgnitedQuery as SQL-string builder instead )

[eluser]sophistry[/eluser]
[quote author="stensi" date="1219903376"]
Scenario:
A group can have many users but a user can belong to only one group. For this situation, I have tested with the <i>group</i> model having the <u>has_many</u>, and the <i>user</i> model having the <u>belongs_to</u>. The user table has an additional column added to it called "group_id". Is this how you would have done it?
[/quote]

@stensi: since i wrote the (admittedly, very basic) original quick start, i'll chime in here:

the answer is: definitely not.

by adding group_id field to users table you have denormalized the database tables and broken the relationship graph. also, you set yourself up for that SQL error where the group_id field becomes ambiguous because it is in two places now.

let's back up a little...the users/groups data model in the quick start implements the prototypical "has and belongs to many" relationship in the data model: "many users can belong to many groups." so, the data model expresses that by first setting up two tables: one for unique users, one for unique groups. to show how each user can belong to each group the data model has a "join table" called groups_users. any time that a user wants to join a group you take the id from the user table and the id from the group table and put them both in one record in the join table. that's what IR helps you do if you set up your datamodel properly.

what you say that you want to do is put constraints on the data model and make it so that a user can only belong to one group. that's a fine rule and you can express it removing the groups_users table altogether. then, you are left with a different relationship graph which is no longer a has and belongs to many, but a simpler "belongs to" relationship.

alternatively, you can express your "users can belong to only one group" in the HABTM relationship but apply your constraints in the model code. so, you'd simply check if there was already a record for that user and do an update on the groups_users table for every operation.

cheers.

[eluser]m4rw3r[/eluser]
I remade that performance test that I've done eariler, because someone mentioned it was a reason for not choosing IR.
But the results were something I wouldn't have expected...

So here is a summary of the results (you can find the full test in the performance section in the manual on SVN):

All are run in 10 000 iterations.

Select one user by id

Code:

IgnitedRecord   5.7295 sec
ActiveRecord    5.6537 sec

Get the related groups of a user

Code:

IgnitedRecord  18.5710 sec
ActiveRecord  167.0000 sec !!! (extrapolated from 1 000 iterations, couldn't get under 30 sec otherwise)

[eluser]m4rw3r[/eluser]
Seems like www.cibase.info is down, so I've uploaded the IgnitedRecord zip files to IgnitedRecord's Assembla space here.