Hey Jurien, This is awesome, from my POV the next step would be to replace the configuration you gave with explicit resources in a Zend Tool Project context. My idea would be:
zf create doctrine.project --for-module=blog It would then create the schema, sql, fixtures, migrations and models folders inside the blog module (if it exists) if they don't already exist and register them inside the .zfproject.xml file. I have a question about your approach though. Can models of different modules communicate to each other in your approach? Could they have relations to each other? Or are they completely separate? Migrations on a per module basis would probably require lots of Doctrine modifications. greetings, Benjamin On Thu, 24 Dec 2009 13:36:39 +0100, Jurian Sluiman <subscr...@juriansluiman.nl> wrote: > Hi all, > I did a commit to put the provider online. It's now at my Google code > repository: > http://code.google.com/p/sozfo/source/browse/trunk/library/Sozfo/Tool/Doctrine/Provider. > > Still pre-pre-pre-alpha ;) > > Please note it's at the very beginning and meant to provide very basic > functionality: > * create db based on doctrine connections > * drop db based on doctrine connections > * migrate db > * generate (php) models (from yaml or db) > * generate (db) tables (from php models or yaml) > * generate (yaml) schema files (from php models or db) > * load data (fixtures) > * dump data (fixtures) > > All on a modular base. A part of the config looks like this: > paths.modules.schema = "configs/schema" > paths.modules.sql = "configs/data/sql" > paths.modules.fixtures = "configs/data/fixtures" > paths.modules.migrations = "configs/migrations" > paths.modules.models = "models" > > This means "zf generate doctrine.models --module=blog --from=yaml" loads > application/modules/blog/configs/schema/ and put the models in > application/modules/blog/models/ > > I'm now thinking of two issues: > * what if you don't provide the module parameter? You could use the global > application models (use application/ instead of application/module/$module > as > prefix). An option is to point to the default module, or loop all modules > and > execute the code for each module individually. > * I'd like to migrate my db on a modular base. Each module should be have > it's > own version number. I'm not sure how to cover this in Doctrine. > > Regards, Jurian
