Re: [coldsync-hackers] Bug report/whine/rant

[Andrew Arensburger <arensb+CShackers@ooblick.com>]

On Mon, 22 Jan 2001, Rich Bowen wrote:
> The data structure that I get of the Memo database contains two parts
> that we're mostly interested in. There's an array of hashrefs for the
> categories. And there's the hash of the records. Each entry in the
> category array looks like:
>
>  {
>   'renamed' => 0,
>   'id' => 20,
>   'name' => 'London'
>  },
>
> Pretty straight-forward and useful.
>
> Each record contains a category field, which contains an integer. It
> seems reasonable to me to think that this integer would be a reference
> to the id number of the category. But it isn't. It's an index into the
> array of category hashrefs.

	Yup. The reason it's this way is that that's what the underlying
PDB looks like. The main requirement here is that $PDB has to contain
enough information that Palm::PDB->Write() can accurately recreate the
.pdb file.

> So, rather than just being able to build a
> hash of id->category name, and reference into that for a category name,
> instead I have to keep the category list as is from the database, and do
> lookups into that. $categories[$id]->{name}.

	You could also build a hash that maps each category ID to a
hashref-to-category, or a category name:

	%id2cat = ();
	%id2name = ();
	foreach $cat (@{$pdb->{appinfo}{categories}})
	{
		$id2cat{$cat->{id}} = $cat;
		$id2name{$cat->{id}} = $cat->{name};
	}

This can be done once when the PDB is read; then you just need to remember
to update %id2cat and %id2name when you manipulate categories.

> While this may seem like a minor inconvenience, it ends up making things
> enormously complicated when they really don't need to be. Would it break
> a lot of legacy code to make the ID number in the record actually the
> category ID number? I suppose I could go through after the fact and make
> this change myself, but I don't understand why the decision was made in
> the first place.

	As I mentioned, the reason the data structures look like that is
because that's what the underlying PDB looks like. This keeps the low
levels relatively simple. Plus, Palm::StdAppInfo is a relatively new and
unpolished addition.
	IMHO, changing the meaning of $record->{category} to mean
"category ID" rather than "index into category array" increases the number
of ways you can shoot yourself in the foot. Or maybe not. Also, I have no
idea what the record's category ID might mean in a database that doesn't
have a standard AppInfo block.

	My preferred solution would be to add methods to Palm::StdAppInfo
for manipulating categories in various ways: "addCategory",
"deleteCategory" and "renameCategory" already exist, so it seems desirable
to add methods to perform other useful functions.

> What I'm trying to do, for the record, is to build, in memory, a hash of
> categories and the data (records) associated with that category.

	One thing you could do would be to add a field to each category
entry:
	@{$pdb->{appinfo}{categories}[3]{_records}} = [];
and have _records be an array of reference-to-record, which gives the list
of records in this category.
	Obviously, this involves more bookkeeping. If you delete a record,
you need to remember to delete it in _records as well.

	At any rate, IMO it seems cleanest to define an API (methods in
the appropriate Perl module) that doesn't change. Then the underlying
representation won't matter as much.

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com			views of ooblick.com
			No anchovies, please.


-- 
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.