Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolves issue #88. Allows static calling of Model subclasses, ignoring namespace info during table name generation. #90

Closed
wants to merge 1 commit into from

Conversation

michaelward82
Copy link
Contributor

Model class static property $_table_use_short_name = true allows static calling of the model subclass whilst avoiding the inclusion of namespace information in the auto generated table name.

…ng namespace info during table name generation.

Model class static property $_table_use_short_name = true allows static calling of the model subclass whilst avoiding the inclusion of namespace information in the auto generated table name.
@michaelward82
Copy link
Contributor Author

This pull request allows static requests to avoid being forced in to using the namespace + class as the auto table name. Consider the following code and the queries generated:

namespace mynamespace;
class Loser extends Model {
}
class User extends Model {
    public static $_table_use_short_name = true;
}

Model::factory('Loser')->find_Many(); // SELECT * FROM `loser`
Loser::find_many();                   // SELECT * FROM `mynamespace_loser`
Model::factory('User')->find_Many();  // SELECT * FROM `user`
User::find_many();                    // SELECT * FROM `user`

Also updates the docs and adds a test.

P.S. I didn't know that using end(explode('\\', $class_name) would cause a Only variables should be passed by reference error in strict mode. Now I do...

@michaelward82
Copy link
Contributor Author

BTW I'm open to changing the static property name - _table_use_short_name was the best I could come up with, but I'm not exactly happy with it.

@tag
Copy link
Contributor

tag commented Apr 11, 2014

IMHO it should be a global setting, not a per-class one. The class already has access to _table, which effectively accomplishes the same thing.

The point, I thought, was to prevent having to set _table in each class.

@michaelward82
Copy link
Contributor Author

I'm happy being able to set it in a single class that inherits from Model then inherit from that class for the rest of my models.

However, I'll code it as a global option if someone can give me an example of existing global options in Paris. So far, the only global options I have seen are for ORM and as that class is part of Idiorm, this option won't prove relevant there.

A global option could be in addition to the per class option, the flexibility may be warranted.

I'd like to get some direction on this before making any further changes.

@michaelward82
Copy link
Contributor Author

I've just seen the Model::$auto_prefix_models option — that looks like an ideal way to implement a global option for Paris.

Still, I'd like some consensus on whether we want to stay per class, go global or have both options.

@michaelward82
Copy link
Contributor Author

As an example of the inheritance I was talking about, I would do something similar to the following:

namespace mynamespace;

class MyModel extends Model {
    public static $_table_use_short_name = true;
}

class Loser extends Model {
}

class User extends MyModel {
}
class Post extends MyModel {
}
class Article extends MyModel {
}

Model::factory('Loser')->find_Many(); // SELECT * FROM `loser`
Loser::find_many();                   // SELECT * FROM `mynamespace_loser`
Model::factory('User')->find_Many();  // SELECT * FROM `user`
User::find_many();                    // SELECT * FROM `user`
Post::find_many();                    // SELECT * FROM `post`
Article::find_many();                 // SELECT * FROM `article`

I haven't tested this yet, but I will do and will report back if it works.

@treffynnon
Copy link
Collaborator

I like the idea so I am going to merge it into develop - please do test that branch. Please do consider a further PR for a more global setting like @tag suggests.

@treffynnon treffynnon closed this Apr 26, 2014
@michaelward82
Copy link
Contributor Author

Ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants