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