IgnitedRecord 1.0 pre-release

[eluser]m4rw3r[/eluser]
IgnitedRecord 0.2.0 is showing some promise, and I've now decided to give all (even those who don't use SVN ) a sneak peek.

Here is IgnitedRecord 0.2.0 Release Candidate 1!

The manual is really huge, 249 kbytes uncompressed, so it will come in the next post.

 

One thing I'd like to have feedback on is IgnitedQuery, my new SQL string builder.
Please try it out to help me find and correct all bugs in it (and always suggest new features if you have any :p ).
Use it like this:

Code:

define('IR_USE_IQ', true);
$this->load->model('ignitedrecord/ignitedrecord');

 

Here is the code, packaged neatly in a zip:

[eluser]m4rw3r[/eluser]
Wohoo, that was the 100th post in this thread!!

I have a feeling that this release candidate have got less bugs than earlier candidates, but that is just a feeling...

Here is the manual:

EDIT: Forgot to note that it is still waiting for completion, but that will be done soon.

[eluser]flojon[/eluser]
Great work m4rw3r!

I've updated the timestamped behaviour and added a option to use localtime and both timestamps can now be disabled if desired.
Also there was a bug which failed to set the timestamps in the object after save.
The new file is avaiable here:
http://dev.koalasoft.se/git/ignitedrecor...tamped.php

I also created a manual page. It's a single file. You can do what you want with it.
http://dev.koalasoft.se/git/ignitedrecor...l?h=manual

[eluser]stensi[/eluser]
Hi m4rw3r. I've been testing IgnitedRecord 0.2 RC1 and have found a bug.

My models all have a suffix of "_model" (example: User_model). The $__table value is automatically setup by IgnitedRecord correctly, as it checks for "_model" and removes it before pluralising. So, for "User_model" I end up with "users" as the table.

However, get_modelname() is missing this check and so my database queries end up looking for the field "user_model_id" instead of "user_id".

Open <b>application/models/ignitedrecord/ignitedrecord.php</b> and find:

Code:

function get_modelname()
    {
        $class = strtolower(get_class($this));

        if($class != 'ignitedrecord')
            return $class;

Replace with:

Code:

function get_modelname()
    {
        $class = strtolower(get_class($this));
        
        // remove '_model' from classname if it exists
        if(strtolower(substr($class,-6)) == '_model')
            $class = substr($class,0,-6);

        if($class != 'ignitedrecord')
            return $class;

Works as expected after that change.

[eluser]stensi[/eluser]
I've run into another problem. Not sure why this is happening.

When I execute this code to delete a record that exists in the database:

Code:

$rec = $this->user->find_by('name','me');
$rec->delete();

I get this error:

Code:

Fatal error: Cannot use object of type IR_RelProperty_habtm as array in /myserver/application/models/ignitedrecord/ignitedrecord.php on line 1067

Any help/advice appreciated.

[eluser]m4rw3r[/eluser]
Some old relation code from version 0.1.1 was still sitting around in delete(), it has now been fixed in revision 70.
I have also added your fix in the same revision (and modified a bit of get_modelname()).

Thanks for spotting those!

@flojon
I've updated your timestamped behaviour + added your manual (modded it a bit to fit the style).

[eluser]flojon[/eluser]
[quote author="m4rw3r" date="1218755531"]@flojon
I've updated your timestamped behaviour + added your manual (modded it a bit to fit the style).[/quote]

Great!

[eluser]flojon[/eluser]
EDIT: Removed...

[eluser]roguewave[/eluser]
I've just come here from Ruby on Rails (looking for a simpler alternative) and after reading through this thread I'm wondering why you did not just take the ActiveRecord (ruby) code and try a straight port it to PHP. (or did you? :-) )

[eluser]m4rw3r[/eluser]
I have ported ruby code to PHP earlier ("my" template parser, to be posted) so it wouldn't be so hard to try porting AR to PHP.

But the hard thing is to make it perform well under PHP, and ruby code is often too object oriented to be accurately ported without some magic from PHP 5 in many places (and it usually ends up in a low performing mess).

The real reason I didn't make a port was that I think RoR's AR is a bit too large and not flexible enough. I also based my implementation around CI's AR, which enabled me to use an already tested SQL-builder (otherwise I had to make a port of RoR's AR's SQL-builder).
I must admit that I haven't used ruby at all so feel free to correct me on any erroneous assumptions I've made.

One of my demands for IgnitedRecord was PHP 4 compatibility and as you can see, IR can run flawlessly on PHP 4.3.2 (at least 4.3.9, I don't have 4.3.2).
But I have also implemented some nice method chaining for PHP 5, so I try to let users decide if they want PHP 4 or 5.