Re:[pilot-db-list] Bugs, features, and random musings (long)

[<mik...@al...>]

Hello,

On Wed, 4 Jul 2001, Chalain Marc wrote:
> Thank you for your remarks, i will try to satisfy you.

As I said, these are long term comments/wishes. I'm actively involved in
documenting a largish Open Source project, so I'm well aware that software
progresses only as fast as the developers can find time and energy. I'm
just db is as good as it is now!

>>  1) In the view editor, it would be nice to have the first line or two
>> of the database displayed to give visual feedback to the spacing
>> changes as they are being made.

>  sorry, my english is too bad to undertand exactly what you want

As you are editing the list view (which columns and how much spacing),
actually display the first one or two records of the database at the
bottom of the screen. The when you tell field 1 to be 20 pixels wide, for
example, have those lines update so you can see the effect of your
changes. If you add a column to the view, then add it to the display.
Often when I am trying to give a field the right amount of spacing ("Gee,
do I want 22 pixels or 24?"), having a short display at the bottom would
make it easy.

>> 4) I was shocked to find that the size of the pdb file was almost
>> the same as the csv file (129,000 bytes vs 130,000 bytes) after a
>> csv2pdb operation. This implies that the booleans are stored as "true"
>> and "false", rather than "0" and "1". That's a tremendous waste of
>> space. Even as integer 0 and 1, over 50% can be saved. Is this really
>> true? (I haven't browsed the code, since I'm not much of a programmer.)
>  It's come from a problem of hardware, the =B5p works with multiple of 8
> bits, then for a boolean we waste 7 bits. The only solution is to
> group all booleans in packets of 8, but we loss the order of the
> fields.

But storing them as "true" and "false" requires 4 and 5 bytes,
respectively. At worst, they could be stored as a native 16-bit integer 0
or 1; this would consume 2 bytes each - a > 50% savings. If they could be
stored as 8-bit bytes, then it's > 75%. Surely either of those would be
preferable to text strings! Again, I haven't looked at the code, so maybe
I'm full of hot air, but _if_ they are really stored as strings, you could
save a lot of space by converting them.


>> 6) For a field with a "date" type, there should be a way to indicate
>> "no date" ...
>  I have the same problem, but the "no date" wonder a lot of code
> implementation, then a lot of memory, my answer is why not but i don't
> know when.

Could you make some arbitrary, but not likely to ever be used date (such
as Jan. 01, 1933) serve as a No Date, and when db detects such a date,
just translate it as "No Date"? This is obviously a bad hack, but maybe it
will suffice until a good fix is possible.

>> 9) Bug in 0.3.2b2 - the "modify" button protects checkboxes when
>> viewing an individual record, but they are editable when in the
>> general list view. This should be made consistent.
>  i saw that it will be correct in the 0.3.2b3 or 4.

Great!

>> BTW, for those who want to squeeze a 10th line onto the main list view,
>> but don't want to recompile DB as suggested in an earlier message, you c=
an
>> use the shareware app RsrcEdit (look it up at PalmGear) to modify db
> Thank Mike but it's depend of the type of field do you use, the height
> of each line is not the same.

Very true - I just wanted to point out an alternate solution for those
that like to live on the wild side :-) Having the 10th line is a real
benefit for my object database ...

Thanks again for a great program! I noticed at least one person
volunteered for documentation. If you would like a "doc team", I'll help
out.

Mike

P.S. Anyone know why my "Author" name shows up as "alum.mit.edu" in the
email archive, rather than something a little more intelligible?

--=20
Mike Ressler
mik...@al...
OK, I'm lame: I don't have my own website ...