The Scarab search system is ... artwork? (what about refactoring...)

Hi;

Now i am completely stuck right in the search engine. Well, ok not the
search engine,
but the Scarab-interface to it. Oh, boy it took me 2 days to create a short
link system
similar to what was implemented for issues and it still does not work as
expected. 
Now i am ready for refactoring ;-(

The goal
======

That's what i would like to have:

  
http://<scarabHost>/scarab/issues/query/<queryId>/template/myPersonalresultListTemplate.vm

Why do i want that ?
I want to support an easy access to the search system, which can be
integrated without
pain. I could go much further here, and create on the fly queries and such,
but thats currently not
my goal, but it could become easy to do with a rewritten search system...

So lets take a look at the data-structures:
=================================

I think, SCARAB_QUERY is the central data here. It contains

- IssueTypeId (always NULL, why that? all my queries are NOT cross issueType
at the moment.. a bug?)
- moduleId (sometimes null, probably so with cross module queries ...)
- listId (which list? maybe the id which was used by the originator when the
query was defined?)

So i only need to know the QueryId and i could already get very far with
that.
Now we also want to take care of the current users settings for the query. 
Remember, everybody can customize the query-result-view (which attributes
they want to see).

We find all mitlists for the user in the table SCARAB_MIT_LIST:

- listid
- userid

Now we can dig into SCARAB_MIT_LISTITEM, which gives us the set of
MIT_LISTS, which apply to the Module/IssueType of the given Query:

- listid
- module_id
- issue_type_id

Good, now we join these informations and get the Set of MIT_LISTS, which
belong to the user and can be applied to the Query. But this is interesting:

I could have multiple queries for the same module/issueType combination, but
from the datastructures only one mitlist is allowed per
user/module/issueType. So all queries on a specific issueType allways are
done with the same MIT_LIST... Is this a feature or a bug here ? Ok, lets
say it is a feature, then:

The logic is:

- i feed the queryId into the system (via URL)
- in the table Scarab_query i find the associated module_id and
issue_type_id (or NULL)
- in scarab_mit_list i find all mitlists associated to the user.
- in scarab_mit_list_item i find all mitlists which apply to the
module/issueType combination.
- by combining the infos from scarab_mit_list and scarab_mit_list_item i
find the mitlists, which apply to the query for the user. I choose the
mitlist which applies best to the query. if no mitlist is available i choose
the default mitlist from the SCARAB_QUERY entry. 
- i perform the search
- i forward the results to IssueList.vm

That's it.

And now ? 
My expectation was that i can implement that based on the given system. 
My fear is, that this is too complex to do. 
My hope is that we can start a refactoring here.
My guess is, that we should better start a complete rewrite ...
My idea is to create something separate from the current search system,
which can build the
nucleaus for a new search system. Its first goal is to provide a convenient
interface for queries.
An interface for reports shall follow...

Now your opinions please ;-)
And please if you think, it could be done better or easier or already with
the current implementation, 
then i would appreciate to get at least a short sketch about HOW that could
be done ;-)

thank you
regards,
hussayn
-- 
View this message in context: http://www.nabble.com/The-Scarab-search-system-is-...-artwork--%28what-about-refactoring...%29-tp23923495p23923495.html
Sent from the Scarab - Dev mailing list archive at Nabble.com.

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=455&dsMessageId=2360279

To unsubscribe from this discussion, e-mail: [[email protected]].