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

Feature request: Ability to extend with our own adapters #125

Open
stilliard opened this issue Apr 22, 2014 · 3 comments
Open

Feature request: Ability to extend with our own adapters #125

stilliard opened this issue Apr 22, 2014 · 3 comments

Comments

@stilliard
Copy link
Contributor

E.g. PDO or other systems could be quickly added this way.

@stilliard
Copy link
Contributor Author

I can open a pull request for this one, but thought best to talk about how it would best work for everyone.
The simplest idea i have for this is to replace the switch statement in the Ruckusing_FrameworkRunner::get_adapter_class() method with a dynamic class name based on the $db_type and run it through class_exists first, so we could just add classes called Ruckusing_Adapter_{TYPE}_Base to extend.
Or maybe a better way would be to have a config variable we pass in under the type, such as adapter_class and have it default to the values in the current switch statement if this new value is not entered.
Any thoughts?

@ruckus
Copy link
Owner

ruckus commented Apr 24, 2014

I'd say the two approaches are basically the same, and I don't have any particular opinion on one or the other.

  • One: infer class from type:
$config = array('type' => 'RocksDb'); 
$class_name = "Ruckusing_Adapter_${config['type']}_Base";
if(class_exists($class_name)) {
  $adapter = new $class_name();
}
  • Two: grab class name from an adapter_class key:
$config = array('adapter_class' => 'Acme_RocksDb_Adapter'); 
$class_name = $config['adapter_class'];
if(class_exists($class_name)) {
  $adapter = new $class_name();
}

Maybe the only advantage to number 2 is that the adapter class can be called anything?

@stilliard
Copy link
Contributor Author

I think the second way is best too as it can fit into people's current naming conventions easier.

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

No branches or pull requests

2 participants