search

edgeflip / faraday

Pythonic modeling framework for DynamoDB
Other
0 stars 0 forks source link

refactor Item/Manager/Table design? #14

Open jesteria opened 10 years ago

jesteria commented 10 years ago

The relationships between faraday's Item, Table and ItemManager make sense evolutionarily, but lead now to an arguably odd state.

faraday.table: superfluous?

The Table shouldn't need to know anything about the Item which reflects it; with the advent of the ItemManager, it can handle conversion from generic boto Items to the appropriate Item type, as well as wrap these results in LazySequence.

And, it would be great to stop monkeying around with boto's Table. This could instead be hidden away on the manager, e.g. at ItemManager._table, and perhaps without any subclassing. The manager's batch_write() could sort out getting the Item to BatchTable. (And, if really needed, Table-specific methods could be supplied by the manager, e.g. describe_table().)

Too much for ItemManager?

This could increase the complexity of ItemManager; but, that seems unlikely, and the reduction in complexity from bringing all our proxying and mapping to one place might be well worth it.

This whole line of thinking did come about simply because I forgot how to access the Item from the ItemManager. I should've just known that it's self.table.item. But this added hierarchy doesn't really make sense, and reducing the circle from:

Item > ItemManager > Table > Item

to:

Item > ItemManager > Item

doesn't really make it worse — perhaps it makes it better. (Though, perhaps the ItemManager > Item, say ItemManager.model, ref should be weak.)

Note: Getting rid of faraday.Table here could arguably be a shallow victory, if we end up opening it back up in pursuit of #13 — but, still probably worthwhile.

jesteria commented 10 years ago

In deprecating the Table class from faraday, we could also perhaps move further from boto's request pattern, and to something more uniform and natural. get_item, query and scan could be made low-level, and replaced with: get (currently "filter_get"), filter and all. And as requested in #7, __OP could be made uniformly optional in all operations, and as intimated in #1, a more flexible and Pythonic interface could be made.

Unification of filter_get and get_item into get would require faraday to recognize when it can perform one or the other; but, that shouldn't be difficult, (and should be similar to how all functions).