Gracias por responderme:
Así fue como lo resolví, el siguiente campo lo deje vacio,
campo auth_user.registration_key=empty
Muchas Gracias por responderme
Saludos
2012/8/1 Johann Spies
> On 31 July 2012 15:50, Anthony wrote:
>
>> With the -S command line option, you can optionally speci
On 31 July 2012 15:50, Anthony wrote:
> With the -S command line option, you can optionally specify a controller,
> and even a function.
>
> python web2py.py -S akb/default -M -N
>
> will give you an environment with the default.py controller exposed, and
> presumably should run the /models/defa
125ms for 10 tables seems high. Perhaps you are using references or
validators which, under the hood, create lists from DB. If you do make sure
you move the settings of those validators where needed.
If you have 200 tables, you should probably break them down into
conditional models.
On Tuesd
migrate=False definitely helps.
Another test:
10 tables, migrate=True: 125ms
10 tables, migrate=Fasle: 120ms
200 tables, migrate=True: 650ms
200 tables, migrate=False: 450ms
--
With the -S command line option, you can optionally specify a controller,
and even a function.
python web2py.py -S akb/default -M -N
will give you an environment with the default.py controller exposed, and
presumably should run the /models/default/db.py model file. You can also
specify -S akb/
On Tuesday, 17 July 2012 19:46:02 UTC+2, Massimo Di Pierro wrote:
>
> I remind the readers we have conditional models:
>
> models/db.py (runs for every action)
> models/default/db.py runs (runs only for actions in controllers/default.py)
> models/default/index/db.py runs (runs only for action index
Seems like a lot. Is migrate=False. migrate=True causes file system access
for every table definition and that is a bottle neck.
massimo
On Wednesday, 18 July 2012 20:10:35 UTC-5, pbreit wrote:
>
> On my Mac, each table added about 6ms. So, yeah that can add up. And
> there's probably a memory
On my Mac, each table added about 6ms. So, yeah that can add up. And
there's probably a memory impact, too.
--
Well, he said ~50 models, not 200. I realize there's superfluous processing
but it might be pretty quick. I haven't seen any testing done on 50 models
versus "model-less" or conditional.
--
Almost 90% of the queries are in DAL and not native SQL. Nothing too
elaborate but there are a number of queries with joins - nothing elaborate
and simple where clauses. I know the model is not the primary bottleneck
as I've got thick controllers that definitely need to be thinned out and
re-
raw maple syrup, well, it flows out of the tree easily enough, and buckets
of it seem almost like water, it's not very viscous. Only when you heat it
and cook it for a while does it become the thick maple syrup you see on
your kitchen table.
On Monday, July 16, 2012 5:14:22 PM UTC-7, wdtatenh
Massimo my suggest was conditionals, Bruno the way I handle mine there is
no repeating of model definitions.
db_tables.py
# define all tables in a function this file should be out side of the
models directory
def define_tables(db, tables=[], migrate=False, fake_migrate=True)
models/global.py <- U
There is an old proposal from Mariano to address that we should revisit
that. Yet I find that if a model is needed by multiple controllers, it can
be defined at top-level. It is in general a good design to group actions in
controllers depending on which models they need.
On Tuesday, 17 July 20
The conditional models are good, but the problem is the fact that they are
not reusable, when you need the same table on multiple controllers, or you
have to define it globally, or you have to repeat the definition on every
sub model.
I think having a module with functions or classes to define the
I remind the readers we have conditional models:
models/db.py (runs for every action)
models/default/db.py runs (runs only for actions in controllers/default.py)
models/default/index/db.py runs (runs only for action index() in
controllers/default.py)
This speeds things a lot.
On Tuesday, 17 Ju
Just think about it loading a page that queries from one table, and models
that define 200 tables. For that single query 200 tables must be define
with the default web2py setup. This isn't rocket science to know it will be
wasting a lot of resources and slow down performance every extra function
ca
LOL well the before and after performance improvements from moving the
models has proven it to be a major problem. So yes models are definitely a
problem primarily because they are redefined every call and with a high
traffic site that means a lot of redefinitions.
On Tue, Jul 17, 2012 at 9:12 AM,
I'd be surprised if model processing is your biggest problem. Have you reviewed
all your queries for optimization opportunities? Cache, cache and more cache?
Indexes?
--
Yeah that is what I was just sharing. My site was slow I have over 200
models now.
My setup is:
models/controller/action/db.py <- In here it includes a function
define_tables(db, tables = [], migrate=False, fake_migrate=False)
The define_tables is a function that I put somewhere else out side of
When I go through the exercise of re-tooling this site I will catalog what
I did wrong and what I had to do get it right based on the input provided
and perhaps it will be some benefit to others who won't make the same
mistakes I made. :>)
--
Yeah I use both approaches, model-less + model folders so I don't have to
import in the actual controllers. I also just use functions instead of
classes to prevent all the extra overhead.
On Mon, Jul 16, 2012 at 2:07 PM, wdtatenh wrote:
> Thanks very much. I'm thinking that I'm probably going t
Thanks very much. I'm thinking that I'm probably going to have to go to a
model-less app because this is going to be much bigger given the breadth of
what I'm trying to accomplish.
On Monday, July 16, 2012 4:52:56 PM UTC-4, Derek wrote:
>
> There should be no benefit to moving them to multiple
Thanks very much for this information. I need to examine it more closely
but it looks darn good. I'm hoping with this change and re-organizing my
controllers, then my site will speed up significantly. At present, it is
slower than raw maple syrup and I can't afford to stay with web2py if I
ca
Split models folder into multiple folders 1 per controller then define
tables used for each controler.. for more fine control add folders inside
the folders you just created with one per controller action and define only
tables used for that action.
On Jul 16, 2012 2:47 PM, "Anthony" wrote:
> The
>
> There should be no benefit to moving them to multiple model files. It
> would have the same performance (or perhaps slower).
>
> The models file is processed on every page load, so it can get expensive
> if you have a lot of tables defined in it.
> I'm sure Bruno can chime in here, but here
You can also download a modelless app here:
https://github.com/rochacbruno/web2py_model_less_app/downloads
I am using this approach for all my apps ( But I know we have things to
improve)
On Mon, Jul 16, 2012 at 5:52 PM, Derek wrote:
> There should be no benefit to moving them to multiple model
There should be no benefit to moving them to multiple model files. It would
have the same performance (or perhaps slower).
The models file is processed on every page load, so it can get expensive if
you have a lot of tables defined in it.
I'm sure Bruno can chime in here, but here is his recipe
27 matches
Mail list logo
