Hi,
when you created the tables this way, what is the best practice to
drop this tables and create Views?
I want to do this in a Symfony Task, but is this the best practice?
And how can I drop tables and views in a Symfony Task?
On Oct 9, 11:14 am, E_lexy wrote:
> @david I am also interested
Probably, fo find out the correct format for some fields, like TIME
and DATE, I'm going to make a one table database, build a project,
insert by hand some values, and then dump and see the format necessary
to build a fixture file. Somewhere in all my free time this next
week :-(
On Oct 10, 10:24
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 wrote:
> Reverse engineering from an existing DB is just a quick way of
> bootstrapping the start of a proj
@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 a
@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
specif
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
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 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 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
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 the
with views and propel i use
attributes { skipSql: true }
and have an sql-script to build my view in data/sql
isn't there a similar way with doctrine?
--
LG,
Michael Steinböck
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Googl
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
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 li
11 matches
Mail list logo
