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
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@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
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@gmail.comwrote:
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@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
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.
Ew. Sounds like sed or M-x replace-regexp might the most sane solution to that particular problem.
postmodern-devel@common-lisp.net
-
Eli Naeher -
Marijn Haverbeke