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

[Johannes Raggam]

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.

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.

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.

> that was my question as well? is there a reason we need new UID or we could
> reuse existing one? we would still be RFC5545 compliant, right?

i'm of course open for discussion on this problem. but while i want to
support the usecase described above, i couldn't find a better solution
yet.

johannes

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office at programmatic.pro
web:  http://programmatic.pro
      http://bluedynamics.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20131108/50168aee/attachment.asc>