Hi Ran,
You're on the right track with Options and default args.
Parameter name changes can be handled ad hoc with @Key annotation -
however, this will over time create a parallel universe of stringly-
typed db queries which must remember to use the "old" name. Both
strategies will require manual clean up at some point.
Type changes - actually, not so bad. Since anything traversable is a
DBList in the Mongo collection, good news: you can save it as a List
and bring it back as a Vector or an ArrayBuffer or whatever without
blinking. Most numerical types will also convert fine. And you can
convert any field except a map or a traversable to an Option! Maps
and traversables are handled by supplying a default arg.
Even case class type changes can be handled with a little bit of
ingenuity with Options and default args. The real pain happens when
the type hints for class hierarchies are outdated, and I don't have a
good solution for that yet. (Think twice, abstract once?)
The versioning you suggest might be handled with some lifecycle
callbacks and some fast footwork. I am interested. (Although on-
demand conversion could lead to significant slowdown when someone
tries to access hundreds of documents which are then one-by-one duly
updated. Could it ever be more than a toy?)
But before I get distracted by anything else, first I must finish the
Scaladoc and wiki page update, try to track down the class cast
exception heisenbug in Play 2, and actually release 0.0.8. So not
thinking about that now!
Best,
Rose
p.s. this is all making me miss Liquibase so so much....
On Jun 1, 2:28 am, RanUser <
ranuse...@gmail.com> wrote:
> I missed Otto's post here before posting:
https://groups.google.com/group/scala-salat/browse_thread/thread/4f00...