strategy / workflow for managing schema changes

27 views
Skip to first unread message

RanUser

unread,
May 30, 2012, 7:59:26 PM5/30/12
to scala-salat
Hello,

How would you recommend dealing with schema changes overtime? Please
share best practices :)

I understand that Salat will serialize with type hint information
automatically into mongodb. When schema changes occur, I assume it
would be best to read the old version of an entity and convert to new
version immediately (upgrade on read). This will allow the rest of
the application to only deal with the newest schema at any given
time. How would one implement this when using Salat and Mongo?

Do I need to have multiple versions of each case class (i.e.
CompanyV1, CompanyV2, ContactV2..)?

Or only have the newest case class, map the stored entity in Mongo to
the case class manually? For example, get the DBObject using Casbah
and manually map to the new case class? How would Salat DAO help
here?

For example, the following schema revisions have parameter name and
structural changes:

schema v1

case class Company(companyName: String, address: String, contactName:
String)

schema v2

case class Contact(firstName: String, lastName: String, phoneNumber:
String]
case class Company(name: String, address: String, contacts:
List[Contact])

schema v3

case class Phone(type: String, number: String)
case class Contact(firstName: String, lastName: String, phones:
List[Phone]
case class Company(name: String, address: String, contacts:
List[Contact])


Can you provide an example showing how these two revisions would be
handled on read?

Thank you!

RanUser

unread,
Jun 1, 2012, 2:28:47 AM6/1/12
to scala-salat
I missed Otto's post here before posting:
https://groups.google.com/group/scala-salat/browse_thread/thread/4f0098c8ab0e5367

I'll re-focus my question, what specific techniques do you recommend
to implement schema transitions in a running application? Assume you
cannot take the DB offline, and run a process which updates the
schema.

First off, I'm thinking it's best to map the old schema to the new
model on read, so the rest of the application is un-affected. Do you
recommend this?

The only two techniques I can think of:

- Add option fields to your model to deal with old fields in Mongo.
Eventually when you are certain all old fields have been processed/re-
mapped, fix then model.

- Don't use Salat for reading from DB. Use Casbah and manually map
your Mongo fields to your Scala case class. Use Salat for writes to
DB.

Any other ideas? :)

rktoomey

unread,
Jun 1, 2012, 11:47:53 AM6/1/12
to scala-salat
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...
Reply all
Reply to author
Forward
0 new messages