j4mie / idiorm

A lightweight nearly-zero-configuration object-relational mapper and fluent query builder for PHP5.
http://j4mie.github.com/idiormandparis/
2.01k stars 369 forks source link

Table prefix #247

Closed peter-mw closed 9 years ago

peter-mw commented 9 years ago

I know this issue has been brought numerous of times, however i think its really important to have this in Idiorm.

While hacking and extending the ORM class may be a work-around, this really belong to the core of the ORM class.

If i want to use Paris, with prefix i do not have an easy option! Having to perform stunts, just to use simple thing like prefix is not good. This is a major pain in the ass!

I will have to override the $_table variable in Paris, which is a static variable.

Since i cannot override my variable on __construct, because its static, i cannot use prefix easily.


//this code will not use my table name on Testme::find_many(); 

class Testme extends Model
{

   public static $_table = 'testme';

    public function __construct()
    {
        self::$_table = 'my_prefix_testme';

    }

}

If i want prefix i will have to either to extend the Model or the Orm object with my own, which will lead to code bloat.

If you would allow I would like to implement table prefix functionality in Idiorm and make the life of everybody easier.

This will not bring any BC issues, all I am asking is to be merged when its ready.

This functionality is also fairly easy to make.

Let me know your thoughts Simon.

treffynnon commented 9 years ago

I think you're over thinking this. The method supported is to use a constant.

define('DB_TABLE_PREFIX', 'myprefix'); class Example extends Model { public static $_table = DB_TABLE_PREFIX . 'examples'; }

It is both simple and easily readable.

peter-mw commented 9 years ago

You are right that this is a way to use it in Paris, but when i want to use the Orm class directly i still have to do ORM::for_table(DB_TABLE_PREFIX . 'examples') which is a lot less readable than ORM::for_table('examples')

As i see it this can be achieved very easy in the ORM class by adding the prefix in the __construct method or the for_table method

https://github.com/j4mie/idiorm/blob/master/idiorm.php#L545 https://github.com/j4mie/idiorm/blob/master/idiorm.php#L236

It will require just few lines of code

The whole setup will be

ORM::configure('table_prefix', 'my_prefix');

And this will not require putting prefix in all model classes and all the model code will be cleaner. Also i will be able to use the ORM class without worrying about the prefix all the time

I want to try to implement this, just asking to be merged if i succeed

treffynnon commented 9 years ago

Yes, this is a little irritating when working with Idiorm directly however I am not merging any new features into Idiorm or Paris - just bug fixes - as they're both feature complete.

peter-mw commented 9 years ago

Simon i really need the table prefix support in the ORM class.

I don't want to have to maintain my own fork, just because of that. Also the "feature complete" thing is not a valid reason, many people have requested this feature and its clear that we all need it.

If you would allow me i will work on it and make it in the best way that will not break any existing functionality.

Please i really need this otherwise i would not ask for it twice.

The cache functionality #216 was also not needed in the begging, but its logical to add a feature when its really needed.

If i have the table prefix i will be able to integrate Idiorm and Paris in my CMS very easy without the need to perform unnecessary work and also be able to update them.

I REALLY need this, so please allow me to make it

EDIT: I see you referred to Eloquent in #243, which has a prefix support. Maybe i should try it and stop asking.

If you wont allow table prefix feature, i will be forced to look for other option instead of making the code full of ORM::for_table(DB_TABLE_PREFIX . 'examples')::find_many()

treffynnon commented 9 years ago

I admire your persistence, but I disagree with your assertions. Feature completeness is a perfectly valid status for a project.

As for your current problem; there are other ways to solve this. Create an adapter instead of extending the class.

class ORM_Adapter { static $_prefix = 'my_prefix'; public static function table($table) { return ORM::table(static::$_prefix . $table); } }

$model = ORM_Adapter::table('my_table');

peter-mw commented 9 years ago

Thanks this will work. I will need to do the same for Paris.

It would be good to have this in the core instead of having to make more classes

Also a software is never "Feature Complete" :)