| 1 | METATODO: move all of these to trac tickets! |
|---|
| 2 | |
|---|
| 3 | TODO |
|---|
| 4 | ==== |
|---|
| 5 | |
|---|
| 6 | Website/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 | |
|---|
| 26 | Code 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 | |
|---|
| 38 | IDEAS |
|---|
| 39 | ===== |
|---|
| 40 | |
|---|
| 41 | The following items might or might not get implemented and probably need to be |
|---|
| 42 | discussed 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 |
|---|