Bug #1221
closedSystematic solution to querying data
0%
Description
We need to figure out a systematic way of easily creating new queries to query
data using fields that can somewhat easily be configured. It would be really
cool to have a table like this:
QueryTable | QueryFields | QueryType |ResultsTo
---------------------------------------|----------
plot | XYZ | simple |plotOverview
plot | ABCD...XYZ | complex |plotOverview
plot | ABGH | plantFocused|plotWithTaxa
plantConc | ABC | simple |plantDetails
then each query could be called (simple, complex) based on the table to query
(plot and children, obs, commConcept, userDefined, note, etc.), returning to the
user a form which allows the user to specify criteria for each field that is
included in the fields for that query. This form would be built from the fields
that were allowed. Based on the type of field, min&max would be filled in, or
boolean check, or drop-down menu, etc. Once the user presses submit, then off
they go to the resultsPage specified in the ResultsTo column.
OK, so if this is WAY too much, then let's scale back and see what is possible.
But we know we are going to want lots of queries, each with different levels of
complexity and piped to different display options. The above schema could also
easily allow customizable queries that the user could build for him/herself.
Related issues
Updated by P. Anderson about 21 years ago
<gabe> DBModelBeanReader problem: pulling out the entire db
<gabe> if all links are followed to the end we get way too much data
<pmark> any ideas?
<gabe> rules
<pmark> instead of storing a huge list of children and their children and their
children and their children and their children, etc, we could instead store some
object that freezes the query, awaiting later retrieval
<pmark> a sort of virtual result
<pmark> but when you try to access that part data it is fetched then
<gabe> we could do that with the cache
<pmark> totally!
<pmark> InstaCache
<gabe> but we would have huge objects in memory
<gabe> where most of the data is useless
<pmark> FileCache
<pmark> Serialize it
<gabe> it is
<pmark> so then garbage collect it after writing to file cache
<pmark> what am i missing?
<gabe> but sometimes you have to bring it into memory to display, write out as
XML etc.
<pmark> true, but not a huge portion of the entire observation tree
<gabe> so smart reading of the cache portion by portion?
<pmark> exactly
<pmark> could be totally transparent to client
<pmark> would still need rules, I think
<gabe> yes, exactly
<pmark> perhaps simple config per element
<pmark> per element per request
<pmark> (multiple views of same data)
<gabe> not following
<pmark> we might want to retrieve only data from observation
<pmark> or obs. plus strata
<pmark> or obs + plot
<gabe> yes, driven by request
<pmark> by default it should just go to terminals, get all data, all children
<pmark> optionally use progressive caching
<pmark> optionally limit results
<pmark> is this the direction you want it to go?
<gabe> yes this sounds like the direction
Updated by Michael Lee over 20 years ago
This is really the same a 1220, because both have to specify criteria for some
data to get from the db and then display it. Once the viewing capability is up
and running, creating a search page to feed the view (with SQL, criteria, and
result view) will be simple.
- This bug has been marked as a duplicate of 1220 ***