Data dumps are problematic, at least on Postgres. If you don't have your PK fields named 'id' it chokes. I've named mine 'table_name_id'. Data dump doesn't work.
On Oct 8, 8:37 am, david <[email protected]> wrote: > Reverse engineering from an existing DB is just a quick way of > bootstrapping the start of a project. > > Doctrine doesn't handle views very well - although it is aware of them. > > Working around this problem when creating some new Doctrine drivers for > CouchDB & RDF I've used view behaviours and then annotate the schema to > get a clean implementation. > The behaviour handles the view creation and the model gets generated > accordingly referencing/overloading the referenced base table and > importing the appropriate keys. > > The yml looks like: > > locationsInEurope: > tableName: locationsInEurope > actAs: > hasViews: > references: Locations > columns: > country_id: > type: integer(4) > region_id: > type: integer(4) > city_id: > type: integer(4) > district_id: > type: integer(4) > > Regarding data dumps - the doctrine:data-dump task is a better way of > handling extracting and reloading the db. > > On Thu, 08 Oct 2009 11:58:51 +0200, ridcully <[email protected]> > wrote: > > > > > > > > > Hi John, > > > the Problem is when you doing the views this way is, you don't have a > > clean > > deployment anymore then we can't use symfony build-all-reload-test > > for the dev. Team. > > I must use SQL-Dumps and I think this is not the right way, because > > you > > can't change the Model quick and easy. > > > There must be a better way to do this, because we need a the mostly > > clean Deployment without SQL-Dumps. > > > Many thanks for your answer, > > Jörg > > > On Oct 8, 11:47 am, John Masson <[email protected]> wrote: > >> Hi, > > >> We were discussing this at work yesterday. One of the guys came up > >> with the same solution and it sounds quite reasonable. > > >> Out of interest we reverse engineered a schema.yml from a DB that had > >> a view in it just to see what would happen. Symfony includes the view > >> in the schema.yml file just like it was a regular table, but there was > >> nothing to identify it as a view rather than a table that I could see, > >> so presumably if we forward engineered the database from this > >> schema.yml it would have created a table not a view (should have done > >> that just to confirm I guess) > > >> My recommendation would be to create your DB as you want it, then > >> reverse engineer your schema.yml with a ./symfony doctrine:build- > >> schema then build-model, forms, filters etc... Just saves you dropping > >> the tables and recreating the views which you'd have to do if you work > >> in the opposite direction (although it's not such a big deal I guess). > > >> John > > >> On Oct 7, 7:48 pm, ridcully <[email protected]> wrote: > > >> > Hi, > > >> > how can I use Database Views in Symfony with Doctrine? I need them > >> > because of performance reasons. > > >> > My Idee was to create dummys in the model and after building the Model > >> > to drop the dummy tabels and create SQL Views. > > >> > Is there a better way to do this? > > -- > Using Opera's revolutionary e-mail client:http://www.opera.com/mail/- Hide > quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
