Re: [coldsync-hackers] New Perl question; Do I need to keep both ahash and an array?

[Izzy Blacklock <izzyb at ecn dot ab.ca>]

On June 10, 2003 06:05 am, Christophe Beauregard wrote:
> On Tuesday 10 June 2003 00:23, Izzy Blacklock wrote:
> > It seems to be working fine.  Is there an advantage to the exists
> > function?
>
> Yes, especially if you don't need the value.
>
> my %hash;
> $hash{$id} = 0;
>
> exists $hash{$id} evaluates to true.
> $hash{$id}, however, is false.
>
> If you're storing, say, array indices as hash values (or anything else
> where zero or an empty string is a legit value) exists is the only way to
> test for hash membership.
>
> Also, exists has no side effects. For any hash, $hash{'random text'} causes
> the entry $hash{'random text'} to be added to the hash with an undefined
> value. This will create problems should you, say, call keys on it.
> exists $hash{'random text'} will never cause the entry to be created if it
> wasn't already there.
>
> > Am I likely to trigger a bug by not using it?
>
> The way you're using it now, probably not. But you definitely want to get
> into the habit before you start writing stuff where it _will_ bite you in
> the ass.

Thanks.  I understand the difference now.  I'll be sure to add the exists and 
get in the habit of using it.  In this case, the value should never be 0 or 
undef, but you never know what a user might do.  Better to be safe then 
sorry! :)

>
> > >   my @nhSorted =
> > >     sort { $NamesHash{$a} <=> $NamesHash{$b} } (keys %NamesHash);
> >
> > This is what I was missing! :)  This technique may come in handy for
> > something else one day, but I don't think it provides any advantage for
> > my current problem.  This method delays the need to reserve memory for
> > the array up front, at the expense of needing extra CPU time to generate
> > it later.  In the end, I still end up with an array and a hash.
>
> As I said in my original message, "if order matters". For something the
> size and complexity of a conduit it may not be worth bothering, but as
> complexity increases it starts to make a lot of sense to just manage one
> data structure and create any derivatives on-the-fly.

Yes, I could see doing this being usefull in a large program where the data is  
needed in different forms at different times.  In this case, I don't so an 
advantage.  I was hoping there was a way I could use a hash as and indexed 
array without needing to build one.  Obviousely not.  No matter.  What I've 
done works just fine.

Thanks for the feedback though.  

> > > I would, however, question the ordering. If I were doing something
> > > where I was creating two separate cross-referenced databases, I'd
> > > probably be using some kind of record identifier. Palm records all have
> > > unique id's, so that would be my first guess. I don't suppose
> > > TitraxNoteDB records have a field something like "nameid" or some such,
> > > huh?
> >
> > As far as I can tell, the names and notes do use the same record
> > ordering. But you may have a point.  I checked the ID of the records
> > themselves, and there doesn't seem to be any correlation between the Name
> > and the Note DBs. There are however Record index entries in each of the
> > three DBs (TitraxData is the third).  I wasn't sure what they were for
> > before, but now I'm thinking they are for cross-referencing the
> > databases.
>
> Each record will have its own unique record id. The question, however, is
> whether somewhere in the application specific data structure there might be
> the id's of _other_ records.
>
> That probably has more to do with the order in which entries are created
> than anything else. The record id is just that... an increasing number.
> It's assigned by the PalmOS database subsystem for every record that's
> created. There's no meaning beyond that, I think.
>

Ok, so it's not likely of any value to me.  Any idea what the Record Index 
entries are?  They don't have any data, and I haven't seen them in other DBs 
I've peeked at.  Maybe I haven't looked at enough?

> > I'll have to take a closer look at these later.  For now, the records do
> > seem to be indexed by record number as well.  I should look over the
> > source code for Titrax to see if I can make heads or tales of it one day.
>
> I might be giving the Titrax developers too much credit, you know. For me,
> it would seem nuts to create three databases and just assume that they're
> all going to be completely synchronized. PalmOS is a remarkably stable
> system, but still...

Sadly, it looks this way.  I don't see anything except the note/name data in 
the database records.  Mind you, I haven't decoded the TitraxDataDB yet.  
It's possible it holds some sort of indexing entries.  There isn't really a 
lot of data in them though.  I had assumed it was just the total times that 
are kept for each project.  I'll have to read the source one of these days to 
see what I can learn.  Here's a sample of the records.

 Record 1
    00 01 30 a5 ba d8 8e 35 00 01 00 00             |..0....5....    |

        data -> [^@^A0¥ºØ2165^@^A^@^@]
        category -> [0]
        offset -> [492]
        attributes:
        id -> [2240514]

  Record 2
    00 01 18 d9 ba dd 6d 25 00 01 00 00             |......m%....    |

        data -> [^@^A^XÙºÝm%^@^A^@^@]
        category -> [0]
        offset -> [504]
        attributes:
        id -> [2240515]

> >  If you or anyone else has some insight as to how I should decode this
> > info, please let me know.  Below I've provided sample output of pdbdump.
>
> data, category, attributes and id are all managed by the PalmOS database
> layer. They don't have any specific meaning to Titrax. The data is where
> the app-specific stuff is. Normally, data corresponds to a C structure of
> some kind. Well, a C structure with variable length strings tacked onto the
> end. I'm starting to get the feeling that maybe the Titrax folks decided to
> have a separate database for what would normally be just different fields
> in a structure in a single database?

Yeah, the three databases should have been made into one.  There are a number 
of other issues I have with the program.  One of these days, I'll spend some 
time learning how to program for the Palm so I can fix them.  Another project 
for another day...

Thanks for all your help/feedback.

...Izzy


-- 
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.