drop_view_if_exists could allow cascading

Please If somebody else can try this patch is very simple but useful, we try it on our Production Enviroment and make a -u all and everything works fine....

Thanks

Sorry I had generated in an incorrect way the patch.
The correct is this.

Thanks.

On Friday 18 June 2010, you wrote:
> Sorry I had generated in an incorrect way the patch.
> The correct is this.
>
Can you please give a few more details on the case a 'cascade' is needed?
How do we make sure that all views that cascade had dropped, will eventually
be restored?

As a matter of pythonic correctness, I wouldn't put a default dict argument at
the fn(), but rather have context=None and then, at the line:
   .. if context and context.get('cascade', False):

Now that I see, I also wonder why don't we use the 'DROP VIEW IF EXISTS'
functionality.

Good Question.

I'm not python programming expert, if you can propose a patch more elegant
It is welcome ;-)

Let me explain.
case:
I have a view so complicated that calculate a very very special report for
economies of high risk (I'm from venezuela).
My customer needs this complicated view to export it to excel and work with
it later, but, the elegant solution is have all data and then with wizards
filter this data in several ways [Exactly like the customer said], in this
moment we need to generate dinamically view childs for the first one, in
this moment I will need to drop the first one (that is result of one first
wizard) and recalculate it droping the childs, what do i win with this? i
wrote at least 100 lines less of SQL code.

You can see this module in our localization:
http://bazaar.launchpad.net/~openerp-venezuela/+junk/grupo_interno/files/head:/report_profit/
[BIG model]

http://bazaar.launchpad.net/~openerp-venezuela/+junk/grupo_interno/annotate/head:/report_profit/report_profit.py
[CHILDS models]
1.-
http://bazaar.launchpad.net/~openerp-venezuela/+junk/grupo_interno/annotate/head:/report_profit/report_profit_partner.py
2.-
http://bazaar.launchpad.net/~openerp-venezuela/+junk/grupo_interno/annotate/head:/report_profit/report_profit_var.py
3.-
http://bazaar.launchpad.net/~openerp-venezuela/+junk/grupo_interno/annotate/head:/report_profit/report_profit_user.py

As you can see, if i need to replicate the work on the big one in the CHILDS
view it will be unmaintainable or at least unreadable, for this reason the
framework itself should have the ability of drop views on cascade, and in
this way avoid this thing:

**.- For the dificulty of work with several complicated SQL views and Childs
the programers will replicate data in models to access it easily, for data
consistency this is a mistake, IMHO the data _must_ be recorded _only_ in
one field and access to them from several places, to be able to do this the
SQL views must be generated dinamically.

I hope it explain the reason of the report.

Thanks in advance ;-)

2010/6/18 xrg <email address hidden>

> On Friday 18 June 2010, you wrote:
> > Sorry I had generated in an incorrect way the patch.
> > The correct is this.
> >
> Can you please give a few more details on the case a 'cascade' is needed?
> How do we make sure that all views that cascade had dropped, will
> eventually
> be restored?
>
> As a matter of pythonic correctness, I wouldn't put a default dict argument
> at
> the fn(), but rather have context=None and then, at the line:
> .. if context and context.get('cascade', False):
>
> Now that I see, I also wonder why don't we use the 'DROP VIEW IF EXISTS'
> functionality.
>
> --
> drop_view_if_exists Dont allow Drop on cascade
> https://bugs.launchpad.net/bugs/595716
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenObject Server.
>
> Status in OpenObject Server: In Progress
>
> Bug description:
> In the method
>
> drop_view_if_exists
>
> Is not Considered the cascade option.
>
>
>

--
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
+58-212-6615932
+58-212-9536734 ext 124
+58-212-9512643
Skype: nhomar00
W...

Hello Nhomar,

Let's keep this improvement in mind for post-v6, I think we will need to implement a better mechanism for managing things like views and custom indexes etc. to avoid hand-coding it all in SQL, and this could be part of it.

I'm removing the milestone because we cannot consider changing this in 5.0 either (stable=only bugfixes)

Thanks for the suggestion, examples and the explanation of your use cases! :-)