"Auto-sync" questions

[Marijn Haverbeke]

Hi Eli,

I really want to stay as far away from the kind of magic that is
giving database abstactions a bad name. So I don't really think
*db-auto-sync* is a feature that fits in Postmodern.

Doesn't looping over the slots in your class, and defining :after
methods on their setters, solve this without touching the Postmodern
internals? It'll probably be awkward, as any MOP-based method
definition is bound to be, but I believe it should be possible.

Best,
Marijn

On Tue, Jan 28, 2014 at 5:11 PM, Eli Naeher <enaeher at gmail.com> wrote:
> Hello,
>
> I'm in the process of converting an existing application from CLSQL to
> Postmodern. This application makes heavy use of CLSQL's *db-auto-sync*
> feature, whereby new instances of view (DAO) classes are immediately
> inserted into the DB table, and changes to view class instance slots result
> in immediate updates.
>
> While I like the explicit approach of save-dao/update-dao/etc., there is
> just too much code in this application that relies on the auto-sync behavior
> to adopt that approach in the immediate term.
>
> So, a few questions:
>
> - would a *db-auto-sync*-like feature be accepted if I were to submit a pull
> request, or are there philosophical objections to having this feature in
> mainline Postmodern?
>
> - if this feature is not desired, would you be willing to accept a few
> patches that would make it easier for me to build this feature as a separate
> third-party library? Specifically, I'm thinking of something like CLSQL's
> *db-deserializing* flag, which would indicate to my code when it is being
> called by a dao-row-reader (and thus should not propagate slot value changes
> to the database) vs when it is being called by user code.
>
> Thank you,
> -Eli