[elephant-devel] Persistance and Model Validations

[Daniel Salama]

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 at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20060811/4f5de1a1/attachment.html>