[ewiki] Re: new db interface, virtual funcs, ::SEARCH()

I think separate simple and complex searches are probably in order.  The
current one being the simple to provide for searches such as we
currently do and the complex one supporting the next search page.  The
complex search should be able to search title and content as well as
include and exclude words.


Andy
 

> -----Original Message-----
> From: ewiki-bounce@xxxxxxxxxxxxx 
> [mailto:ewiki-bounce@xxxxxxxxxxxxx] On Behalf Of Mario Salzer
> Sent: Monday, July 26, 2004 1:50 PM
> To: ewiki@xxxxxxxxxxxxx
> Subject: [ewiki] new db interface, virtual funcs, ::SEARCH()
> 
> 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
> 
> 
> 
> _________________________________________________
> Scanned on 26 Jul 2004 18:52:49
> Scanning by http://erado.com
>

Other related posts: