I'll see about extracting the code in the next few days and drop a mail when it's done.
On Thu, 08 Oct 2009 22:09:45 +0200, ridcully <[email protected]> wrote: > > Is the view behavior writen by our own? Or can I found this behavior > somewhere? > > Thanx you alot, > Jörg > > On Oct 8, 5:37 pm, 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/ > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
