Bug #1221

Systematic solution to querying data

Added by Michael Lee over 18 years ago. Updated over 17 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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

Blocks VegBank - Bug #1220: Need systematic approach to viewing all data in databaseResolved11/21/2003

Blocked by VegBank - Bug #860: Flexible plot query, user powered: DEMOResolved11/13/2002

Blocked by VegBank - Bug #712: Update the forms for querying plants then communitiesResolved11/13/2002

Blocked by VegBank - Bug #871: Extend the Project Summary view: add more, allow sortResolved11/13/2002


#1 Updated by P. Anderson over 18 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

#2 Updated by Michael Lee almost 18 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 ***

#3 Updated by Redmine Admin over 9 years ago

Original Bugzilla ID was 1221

Also available in: Atom PDF