#26287 [NEW]: sybase_fetch_array() "identical field names" feature
| From: | abazan at filnet dot es | Date: | Mon, 17 Nov 2003 13:49:29 +0000 |
| Subject: | #26287 [NEW]: sybase_fetch_array() "identical field names" feature | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-50478@lists.php.net to get a copy of this message | ||
From: abazan at filnet dot es
Operating system: --
PHP version: 4.3.2
PHP Bug Type: Feature/Change Request
Bug description: sybase_fetch_array() "identical field names" feature
Description:
------------
Hello, I was recently shocked when I discovered the implementation of
Sybase "identical fields".
The PHP manual for sybase_fetch_array() reads:
<snip>
Note: When selecting fields with identical names (for instance, in a
join),
the associative indices will have a sequential number prepended. See the
example for details.
</snip>
I would like to say that I am against implementing these sort of
repetitive
field returns. If a programmer wants multiple (identically named) fields
returned, they can always modify their SQL statement to reflect unique
field names:
select t1.id as id1, t2.id as id2 from t1,t2
PHP should NOT be mangling field names returned from the database driver,
it should simply return the name-value of the LAST field of any given
name.
However, if this is to be kept in the code, there are a few important
considerations that should be taken into account regarding the
implementation:
1st. Upgading PHP. There are loads of cases where you can find in a
database different tables with some identical field names. I know this is
poor database design, but sometimes you find that you have to work with a
design where this occurs. With this new feature on sybase_fetch_array()
all
the code where one just assumed that the returned value for field X was
from the last table selected, MUST BE RE-WRITTEN.
2nd. IMHO, the implementation of this feature is very poor. When you have
a
JOIN over two tables and they have more that one field with the same
name:
table A:
id
date
user
afield
table B:
id
date
user
bfield
the resulting join will result in
id
date
user
id1
date2
user3
afield
bfield
A single numeric index is incremented for all repetitive fields, making
it
impossible to make it dynamic. (if you made a select using different
fields
you will get different field names!!!)
I suggest correcting this implementation to return field names as
follows:
id
date
user
id1
date1
user1
afield
bfield
One counter for each repeated field instead of one unique counter for ALL
fields.
3rd. Last but not least... This is a feature only implemented in Sybase
library functions, so when creating cross-db applications, it is much
more
difficult to implement generic code.
I would appreciate hearing from the PHP Team about this.
Thanks in advance,
Alex
----------------------------
Alex Bazan
abazan at filnet dot es
--
Edit bug report at http://bugs.php.net/?id=26287&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26287&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26287&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26287&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26287&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26287&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26287&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=26287&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26287&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=26287&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=26287&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26287&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26287&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26287&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26287&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=26287&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26287&r=float