[elephant-devel] Re: Mixing "logical" layers in an elephant application

[Alain Picard]

"Alex Mizrahi" <killerstorm at newmail.ru> writes:

>  AP> When I tried the above, it blew up when I added the
> ENSURE-TRANSACTION
>  AP> clause; because all of a sudden the DOQUERY found itself querying
>  AP> on the "wrong" database.  (I'm assuming ENSURE-TRANSACTION binds
>  AP> something like a *DATABASE* var which got mistakenly inherited by
>  AP> the postmodern layer)
>
> so you have two postmodern connections?

At least.  By which I mean that I want to use connection pools,
both at the elephant and "raw" postmodern levels.

Adding a WITH-CONNECTION in the judicious place:

    (defun map-visits (fn thing-id &key (from 0) (to 9999999999)
collect)
      (let ((results '()))
        (flet ((collector (thing)
                 (push (funcall fn thing) results)))
          (let ((fn (if collect #'collector fn)))
           (pomo:with-connection ("otherdb" "postgres" "" "localhost" :pooled-p t)
             (doquery (:select thing-id
                              :from :visit
                              :where (:and (:= thing-id id)
                                           (:< from 'timestamp)
                                           (:<= 'timestamp to)))
                (arg)
              (funcall fn arg)))))
        results))

Does indeed allow the calling code to MAP-VISIT on "otherdb"
while the FN being passed in is a closure which uses elephant
to perform operations on "elephantdb" in the meantime.

It _seems_ to me that if FN throws, it's transaction should unroll,
and since MAP-VISITS is just doing a select, it doesn't need to be
in a transaction, but if it were, it would also unroll correctly.

I'll go with this for now and report problems if I find any.

Thanks for the advice!

                --Alain


-- 
Please read about why Top Posting
is evil at: http://en.wikipedia.org/wiki/Top-posting
and http://www.dickalba.demon.co.uk/usenet/guide/faq_topp.html

Please read about why HTML in email is evil at: http://www.birdhouse.org/etc/evilmail.html