Hi Leonel,
I like your suggestion, but I always wonder with these sorts of solutions
whether or not you need a separate field in the person_meta table for each
data type? For example:
db.define_table('person_meta',
Field('person', 'reference person'),
Field('name'),
Field('val_string', 'string'),
Field('val_integer', 'integer'),
Field('val_double', 'double'),
Field('val_list_string', 'list:string'),
Field('val_list_integer', 'list:integer'),
Field('val_datetime', 'datetime'),
Field('val_text', 'text')
)
That way you have the option of using the database to do the sorting,
filtering and manipulations. You can also use the web2py validators
directly on the table. Or is the overhead of having so many empty fields
on every record too much?
I'd be interested in your thoughts.
On Saturday, 17 January 2015 06:51:25 UTC+13, Leonel Câmara wrote:
>
> Right now you have 4 types of companies with different profiles, that may
> not always be so, also, company a, b, c or d may change the fields they
> want in the future. What you need is a way to let the companies specify the
> fields they want.
>
> What's more efficient depends on your objectives. I would do something
> like this:
>
> db.define_table('company',
> Field('name')
> )
>
>
> db.define_table('person',
> Field('name'),
> Field('company', 'reference company'),
> )
>
>
> db.define_table('company_person_meta',
> Field('company', 'reference company'),
> Field('name'),
> Field('mandatory', 'boolean'),
> # The next one is optional and just an example in case you want to
> # validate, format, etc for different types.
> Field('value_type', requires=IS_IN_SET(('email', 'url', 'integer',
> 'date'))),
> )
>
>
> db.define_table('person_meta',
> Field('person', 'reference person'),
> Field('name'),
> Field('val'),
> )
>
>
> # Notes when inserting into person_meta you should check it's one of the
> names
> # defined for that person's company.
>
>
> The field names are a bit convoluted because I use check_reserved=['all'],
> but this would give you complete flexibility and would let you use the same
> controller functions for all companies.
>
> For instance, using this model, list all persons from a company with their
> attributes:
>
> Controller:
>
> def show_persons():
> return {'persons': db(db.person.company == request.args(0, cast=int)).
> select()}
>
> View:
>
> {{extend 'layout.html'}}
> {{for person in persons:}}
> <h2>{{=person.name}}</h2>
> <dl class="dl-horizontal">
> {{for meta in person.person_meta.select():}}
> <dt>{{=meta.name}}</dt>
> <dd>{{=meta.val}}</dd>
> {{pass}}
> </dl>
> {{pass}}
>
>
> Both the controller and the view would work for any type of company
> whatever the fields they could want.
>
> This may not be the most efficient in terms of hardware use, but it future
> proofs your app, so it's certainly the most efficient if you want to be
> proactively lazy as I think all developers should strive to be.
>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
