Right now you can't have one model apply to two different controllers with
conditional models. Copy/pasting should work but I would rarely advise
that. Are you running into performance problems? Have you tried any other
optimizations? 48 tables is kind of a lot but not crazy.
> Right now you can't have one model apply to two different controllers with
> conditional models. Copy/pasting should work but I would rarely advise
> that. Are you running into performance problems?
No, but I read the posts in the group, and thought I'd better prevent
running into performa
You must be very careful about multiple copies of table definitions.
Only one copy can be allowed to migrate the table.
Upgrading the tables in a production environment is tedious. First you
must upgrade the models independent of the controllers, then use the admin
app to ensure all the migrat
"I'd better prevent running into performance problems"
I generally advise against premature optimization.
put you table definitions on modules and use conditional models to
instantiate them.
http://zerp.ly/rochacbruno
Em 15/05/2012 05:44, "Annet" escreveu:
>
> Right now you can't have one model apply to two different controllers with
>> conditional models. Copy/pasting should work but I would rarely
I too think Bruno has the right answer, however, when it comes to Python
programming I am not yet proficient enough to translate my model files into
modules and use conditional models to instantiate them :-(
I hope one of you can provide me with a working example that I can explore.
Kind regar
there are some (complex) examples of models in modules floating around the
group. the simple suggestion bruno made would look something like this:
module/mytable.py
def init():
current.myapp.db.define_table()
return
then in your conditional model file:
current.myapp.db= db #get the db conn
Not sure using conditional models is "premature optimization" it is just
better design.
On Tue, May 15, 2012 at 12:14 PM, pbreit wrote:
> "I'd better prevent running into performance problems"
>
> I generally advise against premature optimization.
>
--
--
Regards,
Bruce Wade
http://ca.linke
*# models/db.py*
...
db = DAL(".")
...
*# modules/datamodels/myobject.py*
from gluon import current
from gluon.dal import Field
class MyObject(object):
def __init__(seld, db):
self.db = db
self.T = current.T
self.request = current.request
self.fields = [
Bruno mentioned modules, not conditional models.
Better example:
*# models/db.py*
...
db = DAL(".")
...
*# modules/datamodels/base.py*
class BaseModel(object):
def define_table(self):
self.db.define_table(self.tablename, *self.fields, **self.params)
*# modules/datamodels/dog.py*
from gluon import current
from gluon.dal import
These examples are only good if you have 1 model per class. I prefer the
design used in Auth with a define_tables method.
On Tue, May 15, 2012 at 12:41 PM, Bruno Rocha wrote:
> Better example:
>
>
> *# models/db.py*
> ...
> db = DAL(".")
> ...
>
> *# modules/datamodels/base.py*
>
> class Bas
Bruce,
Maybe I'm a little simple minded today ...
Could you give an example where you would have more than one model per
class?
On Tuesday, May 15, 2012 3:43:33 PM UTC-4, Bruce Wade wrote:
>
> These examples are only good if you have 1 model per class. I prefer the
> design used in Auth with a
I am looking in to it, and realized that there ia a better, simple and more
elegant way.
In Django models, it is very commom to use a subclass named Meta, so I will
try to run something like.
class Dog(BaseModel):
self.name = Field("name")
self.guardian = Field("guardian", "reference g
Well one example is my location class, which contains countries, provinces,
and cities models. Having one class allows me to write a single API that is
self contained and very modular to handle any location related task.
On Tue, May 15, 2012 at 1:35 PM, Bruno Rocha wrote:
> I am looking in to it
For example see attached, it isn't complete but will give a better example.
On Tue, May 15, 2012 at 1:43 PM, Bruce Wade wrote:
> Well one example is my location class, which contains countries,
> provinces, and cities models. Having one class allows me to write a single
> API that is self conta
And just to be clear, defining models in modules and defining modules using
classes are two independent design decisions -- you can use classes even in
regular model files, and you can use modules without using classes. If you
want, you can just use regular functions in modules:
*/modules/mymod
>
> class MyObject(object):
> def __init__(seld, db):
> self.db = db
> self.T = current.T
> self.request = current.request
>
> self.fields = [
> Field("field1", label=self.T("Foo")),
> Field("field2),
>
>
Thank you all for providing me with examples of how to put my model into
modules. They're very helpful to get me started on this subject.
Kind regards,
Annet.
Doesn't seem like a great idea to be repeating table definitions. Maybe you
should put this one in a non-conditional model file, or define it in a
module and do an import.
Anthony
On Tuesday, July 3, 2012 6:33:28 AM UTC-4, selecta wrote:
>
> In my project I use conditional models since I have a
20 matches
Mail list logo
