Introducing ErlyDB: The Erlang Twist on Database Abstraction

[Yariv Sadan]

Thanks for the thoughts. I think these are very valid points. It
wouldn't be hard to hack Smerl into just spitting out the BEAM files
to a directory. This way, all new app code can be deployed at once.

However -- it should possible to use ErlyDB without taking the system
offline if all schema changes are non-destructive. You would first
update the schema, then call erlydb:code_gen, then load the new
application modules. This way, everything should work. I haven't tried
it, though :)

Best,
Yariv

>
> Hi,
>
> Just a thought: regenerating the code at run-time when the schema
> changes is dangerous. Unless the change is trivial, any client modules
> would need to be updated too.
>
> IMHO it might be better to do the generation at compile time so that
> all changes can be caught and corrected before deploying the whole
> system at once.
>
> BTW, a non-trivial schema change can't be handled without taking the
> system down anyway, so maybe the above is not helping much :-) The
> important observation is that there's much more to think about than
> just generating the abstraction layer.
>
> regards,
> Vlad
>