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

[Mitra <mi...@mi...>]

Ok - so I'm understanding that you think this is a good idea, but 
that it needs to have some extended functionality, specifically:
a:  handling arrays of ids in different formats.
b: Handling quoted and unquoted packedids (I don't understand the 
difference here - maybe another source of errors)

So it seems we have two separate things to decide.
1: External Interface - the series of methods applied to the class
2: Internal implementation.

If we do our job correctly then we can start with a simple internal 
implementation which can then be changed to handle the more complex 
case of very large arrays of ids WITHOUT changing the external 
interface that the rest of the code uses.

I would suggest we need two classes, "id" for handling a single id, 
and "idarray"  for handling arrays of ids?  The interface should 
allow for returning results directly from an "idarray" WITHOUT 
neccessarily instantiating an "id" for example:

$url .= $myid->longid; to return the long id .
OR
$url .= $myarray->longid(10); to return the long id of the 10th id in the array

but not requiring
$url .= $myarray->id(10)->longid.

Am i on the right direction?

- Mitra



At 12:26 AM +0100 14/1/03, Honza Malik wrote:
>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
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
>are you planning your Web Server Security? Click here to get a FREE
>Thawte SSL guide and find the answers to all your  SSL security issues.
>http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
>_______________________________________________
>Apc-aa-coders mailing list
>Apc...@li...
>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders


-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved