@david
The reason we use these views is because we need Subqueries and
Aggregate functions in our views for use in a sfGrid
DatasourceDoctrine.
Looking a bit at your YML snippet, poses a question:
Does you solution provide a way to use subqueries and aggregate
functions?
-Alex
On Oct 9, 11:14 am, E_lexy <alexk...@gmail.com> wrote:
> @david I am also interested in your solution.
>
> My 2 cents:
>
> At the moment we are working with views by letting Doctrine create
> tables from the VIEW model classes, and the overwriting them with an
> SQL to create the actual views.
>
> I have managed to keep the relations (FK) out of the the DB by
> specifying:
> public function setUp()
> {
> parent::setUp();
>
> $this->setAttribute(Doctrine::ATTR_EXPORT, DOCTRINE::EXPORT_NONE);
>
> $this->hasOne('UserView', array(
> 'local' => 'user_id',
> 'foreign' => 'user_id',
> ));
>
> }
>
> Otherwise the DB would create FKs to empty tables, that will cause
> errors in loading fixtures (for testing etc).
>
> I have not managed to keep entire VIEW model classes out of the DB by
> specifying ithe EXPORT_NONE property in this way.
>
> On Oct 8, 11:49 pm, david <da...@inspiredthinking.co.uk> wrote:
>
> > 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 <ohnhei...@googlemail.com>
> > 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 <da...@inspiredthinking.co.uk> 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 <ohnhei...@googlemail.com>
> > >> 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 <jmas...@gmail.com> 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 <ohnhei...@googlemail.com> 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 symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
-~----------~----~----~----~------~----~------~--~---
