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

[hussayn]

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

[Johannes Höchstädter]

Hi,

were there any efforts? Have you reached any goals?

As I remember there were some efforts of Ronny to refactor he search
engine/mechanism.

cheers

Hussayn Dabbous schrieb:

> 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
>  

--

Johannes Höchstädter

memoComp Software Engineering & Consulting
Frank Freund
Michelsberg 28
65183 Wiesbaden
Germany
Fon [phone]
Fax [phone]
Amtsgericht Wiesbaden HRA 4304

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

To unsubscribe from this discussion, e-mail: [dev-unsubscribe@...].