dbv
dbv copied to clipboard
composer?
how about a composer package?
+1 for composer
+1
but maybe we should change the config files. something like
$config = ...
$dbv = new DBV\example($config);
$dbv->authenticate();
$dbv->dispatch();
so we can put the index anywhere in our app with composer. just an idea though
The problem with composer integration is, for now, not following the PSR convention. The autoloader is expecting the files to have the same name as the class they contain, this is not the case at least with the DBV_Adapter classes.
I actually don't have any experience with composer whatsoever. I will look into it, but if someone with greater experience can fork/pull request, it would be most appreciated. Otherwise, it may take me some time to get around to it.
Hey,
this is proposal for composer.json file: https://gist.github.com/diviak/5195026
Let me know if you would add more required things, etc.
Thanks
:+1: Yes please, add composer support (It is just about adding composer.json file in the package root and then add link on http://www.packagist.org and ok, configure github hook to send info into packagist) ;) If you want help, feel fre to ask me ;)
+1
+1
I vote to clone the repository and refactoring the current project, answering the issues and pull requests. I think this is a very important project for the community to be treated as unimportant.
@diviak what happened to the gist you put up as a proposal?
@johnbendi sorry, it's gone.
We are using http://docs.phinx.org/ for migration now.
@diviak thanks for pointing that out.
@diviak is there a document you followed for integrating phinx with wordpress? OTOH, I don't think dbv and phinx handles the same use case. Phinx is a database migration tool while dbv is a distributed db versioning tool.
I agree with your observation @johnbendi Forgive me @diviak, I could be wrong, but it seems bad willing to continue with the project.
@johnbendi not sure what's the difference here. We used dbv for migrations as well but it turns out that phinx is more suitable solution for our needs. We were looking for something which would be easily integrated with our CI proposal.
@celorodovalho not sure what do you mean by that :). I'm not the owner of this project. We use it for a while and does the job for us. We were missing composer support so I proposed solution for it. As we no longer use DBV our focus is more on phinx now.
@diviak I'm sorry, I wanted to mention to the @victorstanciu not you. Sorry.
@diviak can phinx look at the database of one developer and automatically generate the sql diff which can be applied by another developer on the other side. Just the way git versions the source code. That's what I mean by versioning. Migration as dictated by phinx requires you to write your migrations by hand if I understand correctly.
Also since you are no longer using dbv would you mind providing the proposal you put up so that we can continue to look at it and see how we can bring it to implementation.
Another important difference may be that migrations are mostly practicable for schema related changes where versioning might be more practicable for record related changes.
@johnbendi yeah, that make sense.
Thanks.
@victorstanciu my proposal is to just have a composer.json package in the root of this project and register this project with packagist. From there it becomes just a matter of extending it to various environments by requiring it in a customized project where we basically override index.php
to match the logic of the environment say Wordpress Plugins via wpackagist
or somewhere else like Magento or Laravel. So please accept my pull request timely as the content of the composer.json will be solely attributed to you as the author. Other customization authors can take credit in their own respective composer.json
.