@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
-~----------~----~----~----~------~----~------~--~---
