root / elixir / trunk / TODO

Revision 356, 4.2 kB (checked in by ged, 4 years ago)
  • better support for viewonly relationships
  • restore flush method on Entity (accidentaly renamed in r349... ooops)
    (closes ticket #54)
  • Added support for filtered OneToMany relationships. Produce viewonly
    relations. See source:elixir/trunk/tests/test_o2m.py for an example.
  • optimized "inverse" property on relation a bit (if None is found once, it's
    stored and not recomputed over and over)
  • embryonic debugging output
Line 
1METATODO: move all of these to trac tickets!
2
3TODO
4====
5
6Website/doc related
7-------------------
8
9- extend the tutorial !!! (but we shouldn't duplicate the FAQ though)
10    - default values
11    - required fields
12    - multiple files (modules) models
13    - demonstrate common raltionships options (order_by, ...)
14    - inverse relationships matching (with a link to BehindTheScene)
15
16    ? autoload
17    ? many2many with intermediary object (extra fields in table) -> FAQ?
18      -> tags with created_by
19
20    ? transactions
21    ? table constraints
22    ? multi-thread
23    ? multi-database
24    ? deferred fields
25
26Code related
27------------
28
29- Besides, the current system also has another case I don't like: if the user
30  specifies an inverse (on one or both sides) but also set a table name on one
31  side (or two different table names), it will consider the relation as being
32  different even though the user explicitly told it was the same. This should
33  not happen. The system should rather throw an exception in that case. But
34  this last part should be easilty fixable, I think (it'a a matter of tweaking
35  the is_inverse method of the HasAndBelongsToMany class)...
36
37
38IDEAS
39=====
40
41The following items might or might not get implemented and probably need to be
42discussed before doing anything.
43
44- check that relations/fields setup with through kwargs endup with correct type
45  and cardinality (using a finalize method in HasField and Relationship)
46
47- provide optional __init__ kwargs validation (cfr. assignmapper) (as a
48  recipe)
49
50- provide optional "runtime setattr" validation (as a recipe?)
51  http://www.sqlalchemy.org/trac/attachment/ticket/547
52  * the provided "_find_class_descriptor" seem overly complex though
53  * the (unlikely?) case where a parent who is not inheriting from XFBase (or
54    Entity) defines a property will probably fail because of line 16.
55
56- add __revision__ (+ svn property) to all elixir files?
57
58- support all mapper arguments which take column arguments in a generic way
59
60- instead of linking the descriptor in the entity (cls._descriptor) we could
61  do it externally, like the mappers in SA. This would solve some of the
62  ugliness we have in the current implementation (mostly in target).
63
64- add polymorphic references
65  For the syntax, I'd like to have either belongs_to relationships
66  without of_kind argument or with a special "constant" argument like:
67    belongs_to('rel', of_kind=ANY_KIND)
68  Maybe this would be better suited on SA side or in an addon to Elixir and
69  not in the main lib?
70  The implementation would be a bit similar to what Jonathan does at:
71  http://cleverdevil.org/computing/52/making-a-statement-with-elixir
72  we would "just" need to generalize the target_id to support multi-column-pk
73  and I think we would be good to go for belongs_to relationships
74
75  The problem is to keep the referencial integrity of the database. Obviously
76  it's not possible to do that if people modify their data through SQL
77  directly (or at least it would involve complicated triggers on the DB and
78  that wouldn't be portable. It should be possible to do it through the ORM
79  though.
80  See:
81  http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/examples/poly_assoc
82
83- investigate whether it would be possible to do a generic acts_as(xxx)
84  instead of the acts_as_taggable Jonathan demonstrated
85
86- support custom selectable on relationships, as is done at:
87
88  http://spyced.blogspot.com/2007/01/why-sqlalchemy-impresses-me.html
89  ie relations using any "selectable" instead of the normal object table.
90
91    mapper(User, users,
92        properties={
93           'orders': relation(mapper(Order, orders), order_by=orders.c.id),
94           'max_order': relation(mapper(Order, max_orders, non_primary=True),
95                                 uselist=False, viewonly=True),
96        })
97
98    would be something like:
99
100    # Order class must be defined before
101    max_orders_by_user = select([func.max(Order.c.order_id).label('order_id')],
102                                group_by=[Order.c.user_id]).alias('max_orders_by_user')
103    max_orders = Order.table.select(Order.c.order_id==max_orders_by_user.c.order_id).alias('max_orders')
104
105    class User(Entity):
106        has_one('max_order', of_kind='Order', selectable=max_orders)
107
108- get some inspiration from Django
109    symmetrical on M2M
Note: See TracBrowser for help on using the browser.