[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [coldsync-hackers] New Perl question; Do I need to keep both ahash and an array?
On June 7, 2003 05:45 pm, Christophe Beauregard wrote:
> All you'd need to do now is use the "exists" function:
>
> foreach my $record (@{$pbds{DatabookDB}->{records}}) {
> next unless exists $NamesHash{ $record->{"description"} };
> ... stuff ...
> }
Currently, I'm not using the exists function. ie, my next statement is as
follows:
next unless $NamesHash{ $record->{"description"};
It seems to be working fine. Is there an advantage to the exists function?
Am I likely to trigger a bug by not using it?
> For your second example, things are a little more complicated. First,
> however, I have to ask a question... Are you absolutely positive that the
> record ordering between two different databases is going to be the same?
> You seem to be assuming that record $i in TitraxNameDB is the same as
> record $i in TitraxNoteDB. I'm not sure how Titrax organizes its databases,
> so I have to ask. Record ordering isn't always under the control of one
> app. Sync, for example, could mess with it.
See below...
> Assuming you _can_ make the assumption, you need to modify the creation
> code as follows:
>
> my %NamesHash;
> my $i = 0;
> foreach my $record (@{$pdbs{TitraxNameDB}->{records}}) {
> my $text = $record->{data};
> $text =~ s/\\/\\\\/g;
> $NamesHash{$text} = $i ++;
> }
I had tried this myself, but couldn't figure out how to use it like an indexed
array.
> In order to use it, you're almost certainly going to need to make some kind
> of temporary array similar to what you already had because you need to
> preserve the ordering. Something like:
>
> 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. :( Not that it should be much
of a problem either way. By default, there shouldn't be more then 50 entries
for project names. I don't know what the upper limit is that Titrax can
handle, but I'm sure the Palm's limited memory will keep it within reason! ;)
> 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?
>
> c.
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 of the Record index entries has a 6 digit hex ID that isn't an exact
match between the three files, but may be an encoded index. The first three
digits seems to be the same within a file, but different between the three.
I'm thinking it indicates the record type (ie, name, note, data). The last
three digits could be the record number. It's an incrementing value that IS
the same between the three files.
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. 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. I've snipped all but
the first two Record index and Record entries from each file.
Here's a snip of the pdbdump output for TitraxNamesDB.pdb
Record/resource index header:
00 00 00 00 00 32 |.....2 |
Next index: 0
# records: 50
Record index:
Record index entry 0
00 00 01 e0 00 8c d0 01 |........ |
Offset: 480
Attributes: 0x00
Category: 0
ID: 0x8cd001
Record index entry 1
00 00 01 e4 00 8c d0 02 |........ |
Offset: 484
Attributes: 0x00
Category: 0
ID: 0x8cd002
[....snip.....]
Records:
Record 0
57 41 4d 00 |WAM. |
data -> [WAM]
category -> [0]
offset -> [480]
attributes:
id -> [9228289]
Record 1
57 41 4d 32 00 |WAM2. |
data -> [WAM2]
category -> [0]
offset -> [484]
attributes:
id -> [9228290]
And from TitraxNoteDB.pdb
Record/resource index header:
00 00 00 00 00 32 |.....2 |
Next index: 0
# records: 50
Record index:
Record index entry 0
00 00 01 e0 00 37 80 01 |.....7.. |
Offset: 480
Attributes: 0x00
Category: 0
ID: 0x378001
Record index entry 1
00 00 11 fa 00 37 80 02 |.....7.. |
Offset: 4602
Attributes: 0x00
Category: 0
ID: 0x378002
[ ......snip.......]
Records:
Record 0
data -> [ SNIPPED ]
category -> [0]
offset -> [480]
attributes:
id -> [3637249]
Record 0
data -> [ SNIPPED ]
category -> [0]
offset -> [4602]
attributes:
id -> [3637250]
--
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.