Re: [Apc-aa-coders] IDS - maybe a change to make - lets discuss

[Honza M. <hon...@ec...>]

On Po, 2003-01-13 at 14:45, Mitra wrote:
> Hi
> 
> There is a lot of code, and a lot of mistakes, that happen around the 
> different representations for  item ids. We have at least four that I 
> know of:
> Short id: Sequence of Item in database, used in shorter urls 
> especially in views
> Packed id: 128 bit packed, stored in database
> Unpacked id: 32 character, used in urls
> Tagged ids: For example where an x is on the front of a packed id to 
> indicate bidirectional.

1)
In some cases it is unfortunately needed to distinguish between
packed&quoted and packed&unquoted :-(

2)
The 'x' ('y' and 'z' resp.) characters are there not only as the flag of
relation direction. There was some problem with 32 characters long
hexadecimal numbers in array index (a[54637ac9bec645...]) when posted to
PHP from HTML form. I think the problem was, that if the hexadecimal
number begins with digits, PHP thinks the index in decimal so it
produces a[54637] in our example. The begining 'x' tells PHP to
interpret index as string.

> An example of a Sysadmin mistake was where recently I used related 
> items window and stored the string, which then broke something using 
> it as a related items link. I had to switch to store item ids.
> 
> The reason this came up for me, is that I need a way to add a meaning 
> to related item links, which is hard with since a multi-value field 
> (like a related item) can only contain one piece of data. I was 
> thinking of extending the related item window to allow me to redefine 
> the buttons.
> 
> What I'm thinking is to add a "class itemid" which would refer to an 
> item.  This could be initialised with either shortid, packed, 
> unpacked or tagged, and then could - via methods - return any of the 
> alternatives e.g.
> 
> foo = new itemid(123)
> #new itemid(1234567890abcdef1234567890abcdef)
> 
> and then foo->packed;
> 
> I would use lazy evaluation to do the conversion, i.e. only 
> generating the flavors needed.
> 
> What do you think?

I had very simillar idea, only the reason is another. In my thoughts it
was not object for storing single item_id, but it was rather
item_ids_set (foo->short(4) gives you fourth short_id from the set).

Reason:
There are several places where we works with the sets of ids. Very
important function QueryIDs() returns IDs as a numbered array of 32
characters long hexadecimal ids (= unpacked). When we have slice with
50.000 items, the storage of all item ids in the slice exceeds 1MB. 
- We already encounter some memory limit problem.
- It is for example impossible to call serialize() on such array (as
  PHPLib sessions does to cache the result) - it is too big.

I thought about implementation it as classic C-like array of 4B integers
in one memory block (string), where we would store short_ids:

function short($n) {
  return transform4B_2_short( substr($this->heap, $n*4, 4)));
}
Which should be quick and memory efective. The inner implementation is
just detail.

> If we like the idea, I would see it programmed in gradually, i.e. I 
> define the class, and its methods and then it can be integrated only 
> when we are working on some part of the code.

Agree.

> - Mitra
> 
> P.S. I'd still like a hint on how to create a new "item" refering to 
> an item id, this would be very useful for use of the site module, but 
> I can't figure out if this is possible.

I'm not sure I understand, what you need.

   Honza