[Framework-Team] additional index for plone.app.event

David Glick (Plone) david.glick at plone.org
Fri Nov 8 18:14:25 UTC 2013


On 11/8/13, 2:51 AM, Johannes Raggam wrote:
> On Fre, 2013-11-08 at 05:36 +0100, Rok Garbas wrote:
>> Quoting David Glick (Plone) (2013-11-08 03:45:05)
>>> On 11/5/13, 1:07 PM, Johannes Raggam wrote:
>>>> Any thoughts or suggestions?
>>>>
>>>>
>>> It seems like when importing you could just strip off the domain and use
>>> the existing UID index? We shouldn't add a new index unless we really
>>> need it, because it makes writes slower and increases the chance of
>>> conflict errors.
> you mean, on importing, that instead let plone generate a uuid on event
> creation, i should just write the external uid into the UUIDIndex? i
> don't think that this is a sane behavior - we expect plone.uuid (or
> whatever) to do that and not rely on external uid values, which might
> not follow RFC4122.

Oh, I see, you want to support event ids from an external source, that 
weren't generated by plone.app.event. That's the piece I was missing.

> also, while we can omit the domain name when exporting, and thus
> exporting the plone.uuid value directly, i think we cannot cut the
> domain name from external events, because it's just part of their uid
> (we want still be able to export that, right?).  ....(thinking again of
> this, i still can store the external uid on the content itself, so this
> argument is not so strong...)
>
>>> If we do need to add this index for some reason that I'm missing, it
>>> should be a UUIDIndex instead of a FieldIndex so that we don't have to
>>> store an IITreeSet for each index term (since there should only be one
>>> event for each event_uid).
> aha, hm... so, an IITreeSet is stored, I didn't think about that.
>
> on the other hand, i think of a use case, where a UUIDIndex is not
> suitable: having a portal where different users can maintain private,
> different calendars, they might import the same external event. then
> there are many events with the same event_uid and a UUIDIndex cant help,
> am i right?
> the catalog search for existing events currently restricts on the
> current path and does not even search in subfolders.

Hmm, good point.

Too bad we can't give FieldIndex a hint that most of the time a single 
value will be stored, so it could start that way and only upgrade to a 
treeset when needed.

> side note: before releasing 1.0, i renamed event_uid index to sync_uid,
> since i think that this concept can generally be used within plone for
> any synchronization tasks.

+1. I would have called it external_id (it's the id from an external 
system, and it's not necessarily unique even within the portal, based on 
the discussion above). But maybe it's too much trouble to change now.



More information about the Framework-Team mailing list