I've got a Data.fs which has been gradually moved from Zope version to
zope version (it's quite possible that the same Data.fs was originally a
Data.bbb!)
We've been getting the SearchIndex deprecation warning for some time, and
I'd like to fix it - as far as I can tell, it's caused by some
From: Sebastian Sippl [EMAIL PROTECTED]
When I send my request, the only things I get back are some MYBRAnI
instance at #123848-tags.
Thats what you get back from catalog queries. Each brain is a small object
that has all the meta-data you have indexed in the catalog as properties.
It's done
From: Sebastian Sippl [EMAIL PROTECTED]
return context.cata({'content' : id,
'date' : DateTime()-7,
'date_usage' : 'range:min',
})
I always get back all catalog items.
You should get back all items that have a date that is set to after
DateTime()-7
Ross Boylan wrote:
I find that when I refresh my product it destroys some of the
containment relationships. Things start failing, and as far as I can
tell the only recovery is to completely rebuild the object.
This is a big problem, and if anyone could explain what is going on
and how to avoid
Anthony Baxter wrote:
I've got a Data.fs which has been gradually moved from Zope version to
zope version (it's quite possible that the same Data.fs was originally a
Data.bbb!)
We've been getting the SearchIndex deprecation warning for some time, and
I'd like to fix it - as far as I can tell,
Matthew T. Kromer [EMAIL PROTECTED] wrote:
Hmm, while what you're referring to is refresh in the sense of a
product reload, it's important to first state that *no* acquisition is
expected to survive between transactions.
But subtransactions are ok, no? get_transaction().commit() is alright?
Matthew T. Kromer [EMAIL PROTECTED] wrote:
Well, the *sneaky* way to do it would be a funky one-time mod to the
object's __setstate__ method -- but I caution against excessive
sneakiness as potentially very frustrating to get right.
Which makes me think...
I don't find right now were was
