On 9 Jul 2009, at 16:51, Sivert Berg wrote:
Hey
Backend: The S4-code is mostly done and working. I guess it could need
some cleanup and commenting (especially the B+ tree code) but I most
of
the code is in place.
Cool!
The collections were also stored in the medialib, but I rewrote that
so
they are saved to {config_dir}/collections/... instead.
Fine.
(Btw: when I was rewriting collserial.c I saw that the old code made
the assumption that different names in the hashtable could point to
the
same collection. I couldn't see a way that would happen so I kinda
skipped it and just handled _active differently. If anyone could
enlighten me and tell me if I was right/wrong that would be great).
I think that was pretty much the only reason, so that should be fine.
Benchmarks: So.. was it all worth it? Well, you tell me:
(Warning: highly unscientific benchmarks)
Looking good!
Any change on insert/update/removal performance?
I think slow queries were those with lots of JOINs (x OR y OR ...) and
especially those that didn't use indices (searching for "*foo*").
Though with coll2 we will most likely want to do those using tokens,
rather than arbitrary substring matching.
Do you have feedback, ideas, questions or anything else just reply or
drop me a line on IRC.
You said one might lose changes, but can S4 end up in an inconsistent
state?
Are sources supported? If not, what are the plans for it?
Is everything denormalized, i.e. all properties flattened on the media
(a.o.t. some higher album or artist entity)?
Are there plans for changes in the API, e.g. properties on higher
entities than just media?
Great work, it seems!
Hope to try that soon!
--
Sébastien Cevey / theefer - bytes.inso.cc
--
_______________________________________________
Xmms2-devel mailing list
Xmms2-devel@lists.xmms.se
http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
