> If it'd be possible to force SESAT into a "dummy" mode where all
> searches returns a pre-defined result without going through fast or
> similar this wouldn't be a problem at all. A GET parameter
> (dummy=true) could be a simple way to use this feature.
:-)
You're in luck, this has largely been implemented already.
Look at (i've attached it as the issue tracker hasn't been migrated to a
public place yet):
https://jira.sesam.no/jira/browse/SEARCH-2989
Template Prototyping: Search requests run off a serialised datamodel
So it is possible (now that the enrichments part is fixed as well) to
save the completed serialised datamodel and reuse it time and time
again. Shouldn't be too hard to hack RunningQueryImpl to utilise this
functionality.
Maybe you'll also be interested in Ola marius' work on 'debugging
velocity templates. this allows you to edit velocity templates and see
that changes without compiling, deploying, or restarting tomcat.
see http://sesat.no/debugging-velocity-templates.html
~mck
--
"Each and everyone of us are Angels with only one wing. We need to hold
on to each other befor we can fly." Leo F. Buscaglia
| semb.wever.org | sesat.no | sesam.no |
Title: [#SEARCH-2989] Template Prototyping: Search requests run off a serialised datamodel
|
Type:
|
Improvement
|
Priority:
|
Medium
|
|
Reporter:
|
Mick Semb Wever
|
Assignee:
|
Anders Johan Jamtli
|
|
Resolution:
|
Won't Fix
|
Votes:
|
0
|
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
Original Estimate:
|
Unknown
|
|
Issue Links:
|
Depends
|
|
must be finished before this can be resolved
|
SEARCH-2149
|
Divide & Conquer AbstractSearchComman...
|
Open
|
|
must be finished before this can be resolved
|
SEARCH-1613
|
DataModel serialisation
|
Verified
|
|
must be finished before this can be resolved
|
SEARCH-3625
|
Bring enrichments into datamodel
|
Verified
|
|
| Sprint: |
SESAT
|
| Ekstern/Intern: |
Intern
|
Ability to run the request off a serialised datamodel to make it possible to do templating prototyping offline.
|
|
Comment by
Mick Semb Wever
[
2007-08-08 09:53
]
|
|
hopefully something can get done by the end of august...
|
|
Comment by
Kent Vilhelmsen
[
2007-08-13 10:13
]
|
|
Are the prerequisites for this tasks in place?
|
|
Comment by
Anders Johan Jamtli
[
2007-08-29 09:08
]
|
|
Yes and first version is ready
|
|
Comment by
Anders Johan Jamtli
[
2007-08-29 09:22
]
|
|
well... enrichments are not part of the datamodel
|
|
Comment by
Anders Johan Jamtli
[
2007-10-15 12:16
]
|
|
AbstractSearchCommand is still using JunkYard.
|
|
Comment by
Mick Semb Wever
[
2007-10-18 11:42
]
|
Part of this is a specification on what parts of the process stack, eg
the RunningQuery, can be DataModel aware and optimised.
This issue is an example where the RunningQuery, or some point in
the process stack, should be made aware that the DataModel contains
everything already as specified and need not continue.
(Maybe this is really up to each search command to be aware?)
This 'awareness' is really the implementation that a specification
should address, and it will be applicable in different forms through
the process stack for all the different dwr calls. Some examples that
come to mind are: fetching next ten results, fetching next single
result, fetching more results from enrichment, navigation drill down,
fetching results for different sort order. |
|
Comment by
Mick Semb Wever
[
2007-10-26 08:31
]
|
|
child issues is complete.
|
Generated at Thu Apr 10 19:14:04 CEST 2008 by Mick Semb Wever using JIRA Enterprise Edition, Version: 3.9.2-#235.
|
signature.asc
Description: This is a digitally signed message part
_______________________________________________
Kernel-development mailing list
[email protected]
http://sesat.no/mailman/listinfo/kernel-development
