On Wed, 2003-11-26 at 09:55, Alex Bazan wrote:
> Hello,
> sorry for the inconvenience of sending this mail directly to you, but
> i've tried several ways (bug reporting, php_dev list...) to get in
> touch with the developers of sybase_ct extension, without any luck.
I received your mail but just didn't have time to answer it in depth
yet.
> Since php 430, there's a new feature on this extension, that applies
> to sybase_fetch_array() and some other sybase_fetch_something
> functions.
I know, it was me who added it:) Since the changes made in one place in
the C sourcecode, it also affects sybase_fetch_object() and you'll find
the same behaviour in sybase_fetch_assoc() which was introduced in the
same patch.
[...]
> This feature was never present in versions before 430 and it's not
> present on any other fetch_array function from other database
> extensions.
Correct. I implemented it as the previous behaviour annoyed me - you'd
have to look at the numeric indexes and the SQL query (counting the
occurances of the field name) to see which one of the names was
"swallowed"...
> I would like to say that I am against implementing these sort of
> repetitive field returns.
Well, it's been implemented for a while (for over a year now, as cvs log
clearly states) and removing it will probably cause other users to
complain... removing this feature is not an option, AFAIS.
> 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
Which they should be doing anyway, IMO.
> 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, as always did.
OK, this is a (rather small) BC break - but the other way around, I
considered it a bug ("field names are disappearing"). I don't know about
what other database extension maintainers think about this, and I guess
you're right I'm the only one whose extension behaves like this. But
maybe it should be considered a bug in other extensions, too?
Anyway, that's why the note was added to the manual[*].
> The principal problem is when upgrading 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,
I would not say so. We have a rather large amount of tables containing
the fields "lastchange" and "changedby". Now, if I'd just experimentally
fire a query something like 'select * from a, b where a.id= b.id' you
used to get something like this from sybase_fetch_array():
array(
0 => 127772,
'id' => 127772,
1 => 127772,
2 => 'Dec 14 1977 11:55 AM',
'lastchange' => 'Dec 14 1977 11:55 AM',
3 => 'Dec 14 2003 11:55 AM',
4 => '[EMAIL PROTECTED]',
'lastchange' => '[EMAIL PROTECTED]',
5 => '[EMAIL PROTECTED]'
);
Well, without the knowledge of the SQL statement, I'd be guessing (and
could, if I knew lots about the tables' contents) that 'Dec 14 2003
11:55 AM' would probably be the contents of b.lastchange. It could also
be any other field, but I wouldn't know - *unless* - I have the field's
name (and I will, using sybase_ct included in 4.3.0, slightly mangled,
but still readable to a human).
Whatsoever, I shouldn't be doing 'select *' in the first place, and am
only doing this for debugging purposes, to see what the tables contain
(just like using sqsh or isql).
> 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.
Why? You'll have additional array keys in your array but how would this
have an impact on well-written sourcecode? I can (and did) think of
implications on scripts using abovementioned SQL statements where column
names are ambiguous and rely on the fact that you'll have one of the
values accessible via string key and the other one only via numeric key
(but which one, if you come to think about it?). They shouldn't count on
it, as anyone might change the order of columns selected in the SQL
query.
Nevertheless, I tested sybase_ct at the company I work for in 350'000+
LOC and it didn't produce any weird side effects, so I assumed this
change would be fine with most users. OK, maybe this was a blatant
assumption.
> Also, 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 fail to see your point here. Could you give me an example (a couple of
lines) what kind of cross-db applications would be affected by this
change?
Come to think of it, you'll never be able to write 100% cross-RDBMS
applications: For example, PostgreSQL does not know identity fields
(implemented via sequences) so there is no such thing as @@identity
there. Also, the hints you pass to Sybase (noholdlock, at isolation x,
index tablename_I4) are not available or constructed differently (MSSQL:
nolock). Or consider built-in functions such as getdate() - called now()
in MySQL AFAIR. etc. pp.
> Thanks in advance for your time, and sorry for my english.
Hope this clarifies my motivation for the changes...
*] Scan the manual for such notes. You will clearly see that from
time to time, functions change their behaviour between releases.
Maybe this is not considered particularily user-friendly and I
know it makes it hard to track down bugs on previously well-
running code, but sometimes changes are either for the better
of the users or are simply inevitable.
- Timm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
