I can't remember, didn't you go through that cron job script here in
the mailing list or was it on IRC, if it was on IRC maybe it would be
a good idea to do it here again?
Will change the put!> implementation, the error was on put so
hopefully that might take care of it...
On Wed, Sep 16, 2009 at 7:55 AM, Alexander Burger <a...@software-lab.de> wro=
> Hi Henrik,
>> (class +Article +Entity)
>> (rel aid =A0 =A0 =A0 (+Key +Number))
>> (rel title =A0 =A0 (+String))
>> (rel type =A0 =A0 =A0(+String))
>> (rel htmlUrl =A0 (+Key +String))
>> (rel body =A0 =A0 =A0(+Blob))
>> (dm put> (Key Val)
>> =A0 =A0(if (=3D Key 'body)
>> =A0 =A0 =A0 (prog
>> =A0 =A0 =A0 =A0 =A0(put!> This 'body T)
>> =A0 =A0 =A0 =A0 =A0(out (blob This 'body)
>> =A0 =A0 =A0 =A0 =A0 =A0 (prinl Val)))
>> =A0 =A0 =A0 (super Key Val)))
> I didn't try this code, and have no direct explanation why you get an
> error upon re-import, but I see a different problem:
> It is not good to nest 'put!>' within 'put>'. 'put!>' builds its own
> transaction with 'dbSync' and 'commit'. This means, that you get a
> preliminary 'commit', which will unlock the database too early.
> So the 'put!>' above should at least be a simple 'put>'. Then
> we might simply use 'super' instead:
> =A0 (dm put> (Key Val)
> =A0 =A0 =A0(ifn (=3D=3D Key 'body)
> =A0 =A0 =A0 =A0 (super Key Val)
> =A0 =A0 =A0 =A0 (super 'body T)
> =A0 =A0 =A0 =A0 (out (blob This 'body)
> =A0 =A0 =A0 =A0 =A0 =A0(prinl Val) ) ) )
> As usual, this 'put>' must run in a transaction (surrounded by 'dbSync'
> and 'commit'), of course.
> I don't know if this solves the original problem though.
> The same situation ('put!>' inside 'lose!>') we have here:
>> (dm lose!> ()
>> =A0 =A0(call 'rm (blob This 'body))
>> =A0 =A0(put!> This 'body NIL)
>> =A0 =A0(super))
> In fact, I never directly remove blobs, and rely on the nightly garbage
> collection to have them cleaned up. So the above 'lose!>' method might
> simply be omitted.
> - Alex
> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe