Opening the $hitlist! (full control on retrieved data)
Author: email@example.com (-GHAN-)
THE CLAIM: Improve the DB-DRIVERS and OPEN THE HITLIST
I would like to have the $hitlist opened! ... or controlled by params which truly would make life a
bit easier! I claimed it here and there and did some workarounds but well ...! So, time to write it down.
(If you don't have a coffee by now this is a good time to get one *s* this text is a longer one)
This could look like:
$retrieve("OCC_LIMIT") = integer, maximum amount of retrieved occs per "RETRIEVE, READ"
$retrieve("POSITION") = integer, starting position for "READ" (...and after having set those two params...)
The well known rules:
if (position > MAX_POSITION)
CORRECT $retrieve("POSITION") to MAX_POSITION and so on ...
Uniface internally handles this already. While we fire the retrieve trigger, Uniface takes the
profile and starts reading (READ-Trigger). The hitlist gets prefilled with the keyfields and is
ready for us to get the occ's. So, what we really work with is a selection of data choosen by the
keyfields in the $hitlist (... or some sort of) The requesting widget in the component gets the
first chunk of occ's and afterwards poll more data as it is requested (depending on the property
set in the widget). This is how it works today.
I believe Uniface will poll the DBMS for the retrieve profile and get some data back (i.e. total
occs in profile, handle for this request and some other things that never will reach the surface).
And so: i do believe there is a possibility to take control of this and make it better! Further
more there are other nifty things, which easily could be implemented in the drivers.
Lets look at a simple thing which could boost SEARCHING within the DB:
UPPERCASE and LOWERCASE of Fields!
I looked it up and the DB's handle this in TWO different syntaxes (which then makes it easy to
implement in a DB driver):
upper(Field) and lower(Field): Oracle, MS-SQL, DB/2 and Informix
ucase(Field) and lcase(Field): MySQL, DB/2 and
Solid Case insensitivity in some situations would be outstanding! But i leave it up to Compuware
to invent a smart way to handle this for us :)
BENEFITS / POSSIBLE ENHANCEMENTS]
1) Reducing the DBMS overhead while working with large entities. Imagine the following
- 1 Entity, 2.000.000+ occs
- you want to jump to position 45.235 => so you go SETOCC 45235 => Uniface reads
the first 45.234 occs and then starts to let you work with it
(Sure, better keys => less problems, i know) If you dont like
this thought, then give it a try and place a "PUTMESS WHATEVER"
in the Read-trigger :) make some coffee- ... this will take a while :))
2) As a result of a reduced data volume: FASTER Applications
3) NO NEED to archieve this by working with READ WHERE any longer!
4) Uniface would enable pagination-stuff NOT ONLY for widgets but also for web!
(yes, burn me, but you Client-Server guys get a benefit of this aswell)
Remember Gertons "Pick-it-up! Music Shop" demo. He did some extra code to let
people do a sort of pagination ... Client-Server has is, the others not!
5) FASTER sorting by letting the DBMS sort and return just a needed slice of the hits!
6) AND FINALLY: Making me a happy man :)
Please feel free to ask or place your opinions to this!