[ewiki] new db interface, virtual funcs, ::SEARCH()
- From: Mario Salzer <mario@xxxxxxxxxxxxx>
- To: ewiki@xxxxxxxxxxxxx
- Date: Mon, 26 Jul 2004 20:49:55 +0200
So it appears this was actually only a little change: the new database
interface is already in CVS (and tarball) for anybody to check out. It
works well, looks nice, the downwards compat. wrapper is already there,
and I'm now only wondering about what new features to add.
Despite what the old interface already provided (ewiki_db::GET, ::WRITE,
::FIND, ::GETALL, ::HIT, ::INIT, ::SEARCH, ::DELETE) this version adds
a few virtual functions and moves some utility code into that new
interface:
· ewiki_db::APPEND($id, $text) adds content to an existing page
and purely virtual stuff:
· ewiki_db::UPDATE($data) has the code from the old ewiki_update_page()
· ewiki_db::CREATE() contains the code from the old ewiki_new_data()
There may be more to add, like an ::BACKLINKS() for example? So that
we have all page data retrieval code at one place (easier to use than
the many different function names we have now).
#
Also planning on extending the ::SEARCH() function goes on. Currently
it looks like:
ewiki_db::SEARCH($field, $content, $ci=1, $regex=0, $mask=0, $filter=0)
where $ci means case-insensitive (currently default, but should be able
to disable this in future), and $regex may go unsupported by some
backends.
$mask and $filter check the {flags} field, and are also present for the
new ::GETALL call (so in future database scans will be quicker, since
_DB_F_BINARY pages don't have to be looked at anymore).
So the current ::SEARCH only allows scanning of one database $field -
and the question is, if we should implement a multi-field search here?
This would mean some overhead and slower queries for the 95% of database
scans we do now. OTH it is better to build such features in, because a
wrapper was always slower.
There could be a virtual ::ANDSEARCH or ::ORSEARCH (I'd say the latter
is more interesting), but that would mean two separate scans (slower).
If we __really__ need such a feature, I'd rather built it in now than
later, since I have to rewrite all the database backends (6x) anyhow.
There is this new "plugins/db/oldapi.php" wrapper, but it's simply no
long-term solution.
mario
Other related posts: