The more I think about this the more I agree with you and the lazy
table approach seems better.
Imagine a situation with three tables A,B,C and two controllers X, Y
where X needs A,B and Y needs Y,Z. Where should Y be defined? Should
it be imported? modules cannot be imported only executed. what if one
changes mind and now A needs Z too bot no longer Y. Do we move code
form one function to another? It is already a mess.
Massimo
On Jun 11, 11:28 pm, Alexey Nezhdanov <snak...@gmail.com> wrote:
> Let me first comment on initial AchipA's proposal.
>
> Splitting models into different files targets same goals as my lazy_tables
> approach: it tries to speed up model load time by excluding the things that
> are _probably_ not needed in this browser request (read controller/function).
>
> The differences are:
> * split models define static sets of tables. You think in advance what tables
> you will need, and you put just them into the model that will be executed for
> this controller
> Pros: same syntax everywhere
> Cons: many model files, in case of heavy optimisation - too many
>
> * lazy tables allow for more dynamic execution. If you know that you'll need
> some table always - you define it as usual. If you not sure - you define it
> as lazy. During runtime web2py automatically decides which one you need and
> finalizes their definitions. You get little time penalty for lazyness, but
> you save more a lot of init time for the tables you do not need.
> Pros: automatic decisions on which tables to init.
> Cons: syntax is different for 'lazy' and 'classic' tables, though
> converting b/w them is very simple (most of the work is one more intentation
> step).
>
> There is one more problem with split models approach though: they are
> too 'hard' and they try to predict the future.
> 1) You may know what tables you do need for this controller/function call but
> that does not neccesary stay fixed in the future. You will need to add more
> and more tables to 'this controller model' as application grows.
> 2) Opposite of (1) - if you stop using some tables in your controller due to
> refactoring you have to remember to delete them from model. With some
> programming approaches ('lazy' in traditional style) that includes 'deletion
> fears' - you have to do something despite it already works.
> 3) In rare cases even the same function of the same controller may need
> different tables depending on post data. For instance - I have a function
> that is named 'combo search' - it does the search either in one table or in
> another depending on what search button was clicked. Both tables are rather
> large, having more than 20 fields each. I'd very much like to avoid
> initialising unused table.
>
> I'd still vote for using lazy tables. Apart from somewhat awkward definition
> syntax they are quite flexible and do not have the drawbacks that I
> described.
>
> Awkwardness of syntax could be changed by coding lazyness into
> SQLTable.__init__ and SQLField.__init__ (and to validator init for
> completeness) but that will be quite intrusive patch.
> After all - if someone wants to take trouble of splitting models into separate
> files - then probably he can afford wrapping each table definition into
> function call instead.
>
> P.S. 'split models' and 'lazy tables' are compartible and could be used at
> once. But I do not really see a benefit in this - combining them will give
> very little speedup which will be further reduced by penalties of 'execution
> check'. Having lazy tables functionality w/o actually using lazy tables
> decreases perfomance a bit - btw - I didn't test for it. Can't right now -
> will have access to that hardware only on monday. Here is idea - we can have
> a 'class LazySQLDB(SQLDB)' (or I can have it directly in my model).
>
> All in all I see these approaches as interchangeable with a slight preference
> to lazy tables.
>
> On Friday 12 June 2009 01:52:29 mdipierro wrote:
>
>
>
> > What is we have folders like
>
> > models/__init__.py
> > models/default/__init__.py
> > models/default/index.py
>
> > and __init__ is executed for every action and controller
> > and default/__init__ is executed for every action in controller
> > default.py
> > and default/index only for the index action, etc etc.
>
> > if there is no folder, then controllers are executed alphabetically
> > (but __init__ skips ahead if present).
>
> > other depencies in models would result in a mess.
>
> > What d you think?
>
> > On Jun 11, 4:39 pm, AchipA <attila.cs...@gmail.com> wrote:
> > > On Jun 11, 10:08 pm, DenesL <denes1...@yahoo.ca> wrote:
> > > > Using the common code in the controller as a model substitute?
> > > > There goes the MVC separation.
> > > > And the other models still get executed.
>
> > > > I think AchipA means execute one model only.
> > > > The problem is that models are executed before controllers (aren't
> > > > they?), but then this points back to using ifs in models as suggested
> > > > by Massimo.
>
> > > Not quite. I recommend we do the same as we do with views. E.g. if I'm
> > > in a stuff.py controller, then
> > > a) if there is no stuff.py in models, we include all models,
> > > convenient for development, friendly to newbies
> > > b) if there IS a stuff.py in models, we include ONLY that, and that
> > > model file is responsible for it's dependencies - see below.
>
> > > > Let's suppose we change that.
> > > > Where do you keep common model code?
> > > > common = used by all ctls, except those with a name
>
> > > Now, for the kicker - in the model we could do an equivalent of
> > > {{extend 'layout.html'}} (=sort of import ?) to include any
> > > dependencies. This would also pull in any 'common' models (just like
> > > we do with layout.html). Note the subtle difference - I don't want a
> > > single EXTRA model to be included - I want to avoid loading
> > > unnecessary models.
>
> --
> Sincerely yours
> Alexey Nezhdanov
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
