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