Robert,
That's exactly what I was referring to, except that instead of using DCM, just use the standard persistence machinery in Elephant (for the main reason that I haven't learned your DCM yet :) ). Anyway, I guess as you guys get closer to integrating the DCM concept(s) into the standard machinery as we discussed a few weeks back, this would be a non-issue since you seem to have that (or similar) functionality already in place. Anyway, just food for thought.
Thanks, Daniel
On Aug 11, 2006, at 5:40 PM, Robert L. Read wrote: Just a quick comment on this --- Ian may have a better idea. Yes, if we offered a nice clean place to put all of those, it would make it obvious where to put validation. (I will certainly think about that in the future.) Here is a technique that I use, that is very effective for me, but not generally applicable: I use DCM, which is in the contrib directory and basically provides wrappers for the create/read/update/destory operations, similar to those you name below. I use :after methods on these operations (specialized on Director classes, since it is generally class dependedent) to send objects to a text indexer in a background thread whenever they change. (I was using Lucene-ws but now use montezuma; it makes sense to do these operations in a back-ground thread since a web-service call might block the thread that needs to get a response on to the glass as fast as possible.) This is an extraordinarily powerful and elegant feature of LISP. If you have a method that gives you a "change point" (I believe that is what you are asking for) then you can easily put a :before method in a completely different file that performs validation and signals an exception or takes some other action that interrupts the intended operation. One of the beauties of this is that the validation rules can be easily kept quite separate from the rest of the code. I suppose this same technique could be applied even if you do not have clearly defined methods; but personally I consider this clarity to be one of the advantages of the DCM code. Of course, one can more or less easily create your own validation points, without becoming dependeing on the DCM code. Here's my example code: (defmethod register-obj :after ((dir indexing-director) (mo managed-object)) (pub-and-proc (list "indexdocument" dir (k (mid mo)))) ) (defmethod delete-obj :before ((dir indexing-director) (id key)) (pub-and-proc (list "removedocument" dir (k id))) ) "register-obj" and "delete-obj" are defined in DCM. On Fri, 2006-08-11 at 17:17 -0400, Daniel Salama wrote: Hi,
This may be more of a suggestion since I think I already know the
answer.
I come from the Ruby On Rails world and, as some of you may know,
their Active Record module provides hooks that allow the automatic
and customized evaluation of validation rules at different stages of
the committing process.
At first, I was going to as how can I hook validation rules into the
persistent machinery. I guess I could (should) always wrap my commits
in transactions and then I could perform the validation process
within the transaction and, therefore, I could commit or abort
depending on the validation results.
However, as my Lisp knowledge is still limited, I'd like to suggest
for some future version of Elephant, the inclusion of some type of
macro that works somehow like a with-transaction type operation. This
macro could support generic methods that could be "customized" per
class just like CLOS generic methods to support model validation.
Just for reference, Rails validation hooks support, among others:
- before validation
- after validation
- before create
- after create
- before save
- after save
- before destroy
- after destroy
Maybe some of this functionality could be implemented in the near
future. Maybe it's not that big of a deal, but, since my Lisp
knowledge is limited, I am just throwing this suggestion.
Then again, maybe there is a better way to do it and I just have too
much of a Rails mentality for the time being :)
Thanks,
Daniel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________ elephant-devel site list |