2007/4/8, Paul Novitski <paul@xxxxxxxxxxxxxxxxxxx>:
At 4/7/2007 09:49 AM, Martin Alterisio wrote:
>The solution I presented is to access, and act upon, a database as if
they
>were PHP arrays, meaning that a table is presented as an array of
records.
This implies to me that you'll read a series of tables into arrays,
modify the arrays, then update or recreate the database tables from
the arrays. I can't really see how this can work for multiple users
because as soon as a second user reads and starts modifying the data
there will be obvious discontinuities between the two data snapshots,
and updating the tables from one user will erradicate changes made by
others. Is this a single-user application you're working on?
First of all, thanks for replying, I really appreaciate it.
Second, I'm sorry, in my wild search for help I made the mistake of making
assumptions that would only lead to problems of communication. I forgot to
mention the base idea for the implementation. Actually no real arrays are
made, just objects that look and function like normal arrays through the SPL
interfaces ArrayAccess, Countable, Iterator and IteratorAggregate.
Answering your question: no, this will be used in a multi-user enviroment.
Basically all "array" operations will be traslated to the corresponding DB
operation. No caching. No postponing operations. Except for the record
object, which I think I will implement it so that field updates are done on
object destruction, but I'm still thinking about this.
I could index by the order as they are presented by the DB:
>
>$DB['users'][0] is the first user from the query "SELECT * FROM users"
>$DB['users'][1] is the second user from the query "SELECT * FROM users"
>etc..
>
>But this have many cons. First, without a deterministic order, the array
can
>change its logic order on the whim of the DB, nobody assures that the
order
>will be kept after a modification is made to the data, and this can be
>confusing and error prone:
>
>$name1 = $DB['users'][3]['name'];
>$name2 = $DB['users'][5]['name'];
>$DB['users'][3]['name'] = $name2;
>$DB['users'][5]['name'] = $name1;
>
>The last sentence may not be writing to the adequate record.
Hmm. I don't see why this wouldn't work -- you're not changing the
keys (3 & 5) required to point to those unique records. I can see a
problem if $name1 and $name2 were themselves the keys, but you're not
doing that in this example.
Well, it could not work if those operations are translated on the spot to
the corresponding DB action.
If that were the problem, though, you could simply mandate a rule
that you can never change the key of an array element that represents
a data record, so that the record sequence remains what it was
originally. However, making your program logic depend on the record
sequence as it was read from the database seems quite iffy anyway
[especially in a multi-user system]; I'd just use the data table's
primary key as the array key and leave it at that. Random access rocks!
From what you write, it almost seems as though you're assuming that
these statements:
>$DB['users'][3]['name'] = $name2;
>$DB['users'][5]['name'] = $name1;
actually modify the database records they represent. If so, what
system are you using? I just don't see this happening using simple
PHP and MySQL. When you read a data record into a PHP array [with,
for example, mysql_fetch_array()] that array is just a static copy of
the data and doesn't possess any dynamic updating power over the
database. Or are you using an I/O class that you're not showing in
your example code that executes a modifying query each time an "array
element" is changed?
That's actually what will happen. Using the SPL is actually posible. Sorry,
mi mistake for not explaining it throughly.
Another possible indexation could be by the value of the PK, but this also
>have some problems. First, it can be confusing if the PK is an
autonumeric
>int, as this might be seen as a numeric indexation.
You can prefix an autonumber field with alphabetic characters to
force it away from numeric indexing:
$sKey = str_pad($aDataRecord['recno'], $iPadLength,
'pk_00000000000000', STR_PAD_LEFT);
$aArray[$sKey] = $aDataRecord;
e.g., recno 12345 becomes array key 'pk_00000000012345'
Using str_pad(...LEFT) ensures that the array keys will be in the
same sequence as the data records even though the autonumber values
will be composed of differing numbers of digits. You just have to
choose a pad length that equals the longest series of digits your
database will generate for an autonumber field.
But suppose $user holds the info of an user record:
$DB['users'][$user['id']]
I would like that to point to the same user.
Still, I'll think this thoughly. Thanks
Second, not all tables
>have only one field as PK (I can ask that all tables have at least a PK,
but
>I can't ask that the PK is made of only one field).
You can construct a single array key from multiple database fields:
$aArray['pk_' . $aDataRecord['fieldA'] . '_' .
$aDataRecord['fieldB']] = $aDataRecord;
But maybe not all PK fields are numeric. They may contain the separation
character. I don't this strategy will do.
unset($DB['users'][$userid]); // delete
Unsetting the array element, rather than retaining it with a deletion
marker, implies that you're intending to recreate the database tables
rather than update them atomically. Is this correct?
The ArrayAccess Interfase has an unset operation, which will call the
corresponding delete action.
Anyway, it's my fault for not explaining this.
Regards,
Paul
__________________________
Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Thanks again.
