Re: The Scarab search system is ... artwork? (what about refactoring...)
Johannes Höchstädter <[email protected]> Wed, 23 Sep 2009 12:22:23 +0200
| Newsgroups | gmane.comp.java.scarab.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, were there any efforts? Have you reached any goals? As I remember there were some efforts of Ronny to refactor he search=20 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 sho= rt > link system > similar to what was implemented for issues and it still does not work as > expected.=20 > Now i am ready for refactoring ;-( > > The goal > =3D=3D=3D=3D=3D=3D > > That's what i would like to have: > > =20 > http://<scarabHost>/scarab/issues/query/<queryId>/template/myPersonalresu= ltListTemplate.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 suc= h, > 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: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > I think, SCARAB_QUERY is the central data here. It contains > > - IssueTypeId (always NULL, why that? all my queries are NOT cross issueT= ype > 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= .=20 > 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 interesti= ng: > > 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 cho= ose > the default mitlist from the SCARAB_QUERY entry.=20 > - i perform the search > - i forward the results to IssueList.vm > > That's it. > > And now ?=20 > My expectation was that i can implement that based on the given system.= =20 > My fear is, that this is too complex to do.=20 > 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 convenie= nt > 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 wit= h > the current implementation,=20 > then i would appreciate to get at least a short sketch about HOW that cou= ld > be done ;-) > > thank you > regards, > hussayn > =20 --=20 Johannes H=C3=B6chst=C3=A4dter memoComp Software Engineering & Consulting Frank Freund Michelsberg 28 65183 Wiesbaden Germany Fon +49 (0)611 9320054 Fax +49 (0)611 9320059 Amtsgericht Wiesbaden HRA 4304 ------------------------------------------------------ http://scarab.tigris.org/ds/viewMessage.do?dsForumId=3D455&dsMessageId=3D23= 98808 To unsubscribe from this discussion, e-mail: [[email protected]= .org].