Jamie Rumbelow's Flare O/R Mapper for CI - anybody playing around with it?

[eluser]Jamie Rumbelow[/eluser]
I was wondering when a Flare topic would pop up here The first thing I'd like to say is that Flare is in extremely early beginnings. It will be a fully featured, working, documented ORM with some really sexy stuff going on like relationships, single table inheritance and other goodies. It's not quite at that level of maturity yet, as it was mostly written during one night when my insomnia was especially bad, so I'm expecting to find bugs popping up all over the place.

Having said that, it's really helpful having people reporting bugs to me, so please keep going - I really appreciate it and it's really helpful for the system's development.

[quote author="peterphp" date="1261061152"]
Solution for 3):

Code:

$options = array(
             'select'     => 'column3, column5, column7'
             'from'       => 'myTableName',
             'conditions' => array('column3' => 'mySearchTerm'),
             );

$this->data['post'] = Customer::find('all', $options);

// alternative short form
$this->data['post'] = Customer::all($options);

with:
model: customer_model (that's what "Customer::" refers to).

"conditions" within the options-array creates a where statement in the resulting sql.
[/quote]

I think there's a bug - I'll investigate with the select issue you were having and see what I can find.

Workaround for 2):

Well, I now just use the "from"-option above.

There's an inherent issue in PHP and static stuff that means overloading static properties doesn't work correctly. It's pissing annoying. I'll have to go to the drawing board and figure out what the best solution to this problem is, until then, just use the "from" options parameter.

Again, IMHO Jamie delivered a *brilliant* piece of code with Flare, congratulations to that!

Thanks very much!

[quote author="sophistry" date="1261081758"]i hadn't noticed that bit of code until now. thanks for the link.

two things i did notice about the code:

pluralize and singularize are not optimized - in fact, it's the opposite! the code could be easily refigured to test for the most common matches first and then return. instead, it searches the uncommon words first and only at the very last foreach loop does it get to the basic english pluralization of "add an s or es".

also, using CI's last_row() function is a very bad idea (this bug has been confirmed, yet not fixed in CI since April 15, 2009): http://codeigniter.com/bug_tracker/bug/7389/

otherwise, this looks good for PHP5 users!

thanks.[/quote]

Thanks for the comments.

As far as the inflectors go, they work. And I'm happy with that if you're running a huge web app where every millisecond counts (despite the fact you shouldn't be using CI's ActiveRecord, let alone an ORM) then have a go at rewriting them. Until then I'm not going to worry about it because it does it's job perfectly well.

I'm sure EllisLab will fix last_row(), and then it won't be a problem, will it? The only other way to do this would be to return a result array then return the last element of that array, and that's just back to square one.

Cheers.

Jamie