Re: A Minimal PicoLisp DB/GUI Application, Search popup puzzle
Hi Jon, I would like the Telephone field to accept 8-digit numbers, which is common in Norway. At the moment I have to prefix with +47, otherwise I get Bad phone number format. You should change the line in the 'main' function (locale UK) to (locale NO no) Then, entering a number 0123 456 will show in the GUI with a leading zero, but will be stored internally as 47 123 456. Telephone numbers are stored internally always in this normalized format, to allow a uniform search. How difficult would it be to create export and import functions, e.g. to and from tab-separated files? This could be separate utilities, i.e. not a part of the GUI. That's very easy. There is a report mechanism in PicoLisp. You find examples for that in the demo application in the app/ directory. The 'csv' function is called there, e.g. in sales.l and inventory.l. Same with import. You can import CSV or XML (an example for the latter is in http://picolisp.com/wiki/?osmgeodata). But each case is different, depending on the specialities of the format at hand. If you just want an import/export, you could use 'dump'. (load @lib/too.l) (out adrDump.l (dump (db nm +Prs @@)) ) You can then do (load adrDump.l) to read the data back. How about sorting the names case-insensitive? Now Willy comes before von. For a Norwegian, it would also be nice if Å came after Ø, at least in a more serious application than this. I’m just curious. ;-) The search in a QueryChart doesn't come sorted at all. The reason is that this is an incremental search, finding things according to the search criteria (by searching all search keys in parallel). To be able to sort the results, you would need to first select *all* of them, and in a non-trivial application this may be too expensive. To get sorted output, a report again is the standard way to go. I have lots of examples, but unfortunately they are not public ... ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: A Minimal PicoLisp DB/GUI Application, Search popup puzzle
Hi Alex,
Thanks. A few more questions:
I would like the Telephone field to accept 8-digit numbers, which is common in
Norway. At the moment I have to prefix with +47, otherwise I get Bad phone
number format.
How difficult would it be to create export and import functions, e.g. to and
from tab-separated files? This could be separate utilities, i.e. not a part of
the GUI.
How about sorting the names case-insensitive? Now Willy comes before von.
For a Norwegian, it would also be nice if Å came after Ø, at least in a more
serious application than this. I’m just curious. ;-)
/Jon
On 13. Jan, 2015, at 13:42, Alexander Burger a...@software-lab.de wrote:
Hi Jon,
When I’m typing in one of the search fields (Name or Address), a box
with possible matches pops up, but quite often there are names/addresses
missing in this box, and I haven’t been able to find a pattern in this.
If I type a (single) j, k, l, e, i or s, then my name comes up, but not
if I type just o, n or r. Do you know why?
Yes. The 'nm' relation in the DB model
(rel nm (+Sn +IdxFold +String))
uses two index prefixes:
1. +Sn for the soundex algorithm. It stores a condensed and unified
pattern in the DB index tree. In case of e.g. Jon Kleiser this
is JNSLSR. This pattern is used for tolerant searches.
2. +IdxFold applies the 'fold' function the whole name, and stores it
(i.e. jonkleiser) in the index. Then it splits the name on
blanks, 'fold's the fragments, and stores substrings of these
fragments.
But: The substrings are generated only up to a maximal length of three.
This is to avoid storing lots of single- or double-letter tokens - which
are not meaningful to search - in the index.
Thus, jon is stored, but not on or n.
If you dump the index, you'll see what's there:
: (scan '(nm . +Prs))
(JNSLSR {2} . T) {2}
(eiser {2}) {2}
(iser {2}) {2}
(jonkleiser . {2}) {2}
(kleiser {2}) {2}
(leiser {2}) {2}
(ser {2}) {2}
Thus, when you type in the search field, this index is accessed. Typing
iser or only ser will find something, but o, n or r won't.
♪♫ Alex
PԔ � j)mX��� ��zV�u�.n7�
Re: A Minimal PicoLisp DB/GUI Application, Search popup puzzle
Hi Jon,
When I’m typing in one of the search fields (Name or Address), a box
with possible matches pops up, but quite often there are names/addresses
missing in this box, and I haven’t been able to find a pattern in this.
If I type a (single) j, k, l, e, i or s, then my name comes up, but not
if I type just o, n or r. Do you know why?
Yes. The 'nm' relation in the DB model
(rel nm (+Sn +IdxFold +String))
uses two index prefixes:
1. +Sn for the soundex algorithm. It stores a condensed and unified
pattern in the DB index tree. In case of e.g. Jon Kleiser this
is JNSLSR. This pattern is used for tolerant searches.
2. +IdxFold applies the 'fold' function the whole name, and stores it
(i.e. jonkleiser) in the index. Then it splits the name on
blanks, 'fold's the fragments, and stores substrings of these
fragments.
But: The substrings are generated only up to a maximal length of three.
This is to avoid storing lots of single- or double-letter tokens - which
are not meaningful to search - in the index.
Thus, jon is stored, but not on or n.
If you dump the index, you'll see what's there:
: (scan '(nm . +Prs))
(JNSLSR {2} . T) {2}
(eiser {2}) {2}
(iser {2}) {2}
(jonkleiser . {2}) {2}
(kleiser {2}) {2}
(leiser {2}) {2}
(ser {2}) {2}
Thus, when you type in the search field, this index is accessed. Typing
iser or only ser will find something, but o, n or r won't.
♪♫ Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
