zeitgeist team mailing list archive

[Seif Lotfy <seif@xxxxxxxxx>]

I took a look at your suggestions. I would love to go with 3 but i see it as
a big risk and development stall. solution 2 however seems to be for me
someway halfway between 1 and 3. I would say we should go with 2 for now as
a preparation for the hackfest to actually go with 3. having events and
annotations alone in table would lessen the joing and also allow us later to
drop those tables if we want for different databases :)I love the idea
Mikkel thanks for providing awesomeness :)
cheers
Seif

2009/10/8 Mikkel Kamstrup Erlandsen <mikkel.kamstrup@xxxxxxxxx>

> 2009/10/8 Siegfried Gevatter <rainct@xxxxxxxxxx>:
> > 2009/10/8 Seif Lotfy <seif@xxxxxxxxx>:
> >> All I know there should not be any DB
> >> changes except for removing the unused column "end" in the event table.
> >
> > And (at least) changing the content/source URIs.
>
> You mean to use the Nepomuk ontologies?
>
> > Mikkel, I like your new suggestion, although it will make the current
> > huge FindEvents even more unreadable :P (we need to look if there's a
> > better way to write that, like using procedures stored in SQLite or
> > several queries, but it's not that easy as the available filters are
> > exteremly powerful).
>
> Yeah. The complexity in find_events() is indeed worrying... I have
> thought about making a stand alone QueryCompiler class that tries to
> do this as cleanly and self contained as possible. A big problem with
> the current find_events() is that it is incredibly hard to guess
> whether or not we use the indexes in the DB right (and for the record;
> I am quite convinced we don't use the indexes very well now). Another
> big problem is that it is virtually impossible to debug :-)
>
> That said, I am not sure just how much more readable we can make the
> find_events() code given the API we expose. This area clearly needs
> some hard thinking and hard coding :-)
>
> Stored procedures, as you say, might also make things a lot easier.
> And as we discussed on IRC a while ago a few simple queries might
> perform better than one very complex one.
>
> --
> Cheers,
> Mikkel
>
>