<div dir="ltr"><div>Hello,</div><div><br></div><div>I definitely understand your concerns about magic here--I'd prefer the explicit Postmodern approach for sure if I were starting from scratch.</div><div><br></div>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.<div>
<br></div><div>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.</div>
<div><br></div><div>Thank you,</div><div>-Eli</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 28, 2014 at 12:15 PM, Marijn Haverbeke <span dir="ltr"><<a href="mailto:marijnh@gmail.com" target="_blank">marijnh@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eli,<br>
<br>
I really want to stay as far away from the kind of magic that is<br>
giving database abstactions a bad name. So I don't really think<br>
*db-auto-sync* is a feature that fits in Postmodern.<br>
<br>
Doesn't looping over the slots in your class, and defining :after<br>
methods on their setters, solve this without touching the Postmodern<br>
internals? It'll probably be awkward, as any MOP-based method<br>
definition is bound to be, but I believe it should be possible.<br>
<br>
Best,<br>
Marijn<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Jan 28, 2014 at 5:11 PM, Eli Naeher <<a href="mailto:enaeher@gmail.com">enaeher@gmail.com</a>> wrote:<br>
> Hello,<br>
><br>
> I'm in the process of converting an existing application from CLSQL to<br>
> Postmodern. This application makes heavy use of CLSQL's *db-auto-sync*<br>
> feature, whereby new instances of view (DAO) classes are immediately<br>
> inserted into the DB table, and changes to view class instance slots result<br>
> in immediate updates.<br>
><br>
> While I like the explicit approach of save-dao/update-dao/etc., there is<br>
> just too much code in this application that relies on the auto-sync behavior<br>
> to adopt that approach in the immediate term.<br>
><br>
> So, a few questions:<br>
><br>
> - would a *db-auto-sync*-like feature be accepted if I were to submit a pull<br>
> request, or are there philosophical objections to having this feature in<br>
> mainline Postmodern?<br>
><br>
> - if this feature is not desired, would you be willing to accept a few<br>
> patches that would make it easier for me to build this feature as a separate<br>
> third-party library? Specifically, I'm thinking of something like CLSQL's<br>
> *db-deserializing* flag, which would indicate to my code when it is being<br>
> called by a dao-row-reader (and thus should not propagate slot value changes<br>
> to the database) vs when it is being called by user code.<br>
><br>
> Thank you,<br>
> -Eli<br>
</div></div></blockquote></div><br></div>