"Auto-sync" questions

Eli Naeher enaeher at gmail.com
Tue Jan 28 18:34:21 UTC 2014


Hello,

I definitely understand your concerns about magic here--I'd prefer the
explicit Postmodern approach for sure if I were starting from scratch.

Unfortunately I cannot rely on all access going through the writers
specified in the slot definition. Unfortunately there is a great deal of
existing code that uses (setf slot-value), with-slots, etc. in this
codebase.

Right now my approach is to use a (setf slot-value-using-class) :after
method, but of course this method fires when the dao-row-reader is first
populating the slots on a freshly-allocated instance after retrieving the
data from Postgres--hence my question about a *db-deserializing*-type flag.

Thank you,
-Eli



On Tue, Jan 28, 2014 at 12:15 PM, Marijn Haverbeke <marijnh at gmail.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/postmodern-devel/attachments/20140128/d8d1737d/attachment.html>


More information about the postmodern-devel mailing list