By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,719 Members | 1,224 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,719 IT Pros & Developers. It's quick & easy.

PHP and SQL portability

P: n/a
I just ported one of the apps I wrote using PHP 5 under Windows to
PHP 4 under unix.

I knew I wanted to deploy in this environment - and wrote my code in
anticipation of running in the other environment.

A brief summary follows:

Portability was not too bad. However there were several problems I did
not anticipate.

One was that MySQL behaved completely differently. It didn't like
the quotes I used. It objected to several simple SQL statements that
I was amazed to find weren't as portable as I had hoped. SQL portability
even between different versions of MySQL seems poorer than I had expected
it would be.

I also had two PHP language problems.

One was that integers I had used as unique IDs in database fields
started showing up as "1.556564658E18" under unix - and then they
failed to match against the contents of the database they had come
from. The same code worked on PHP 5 under Windows.

The other problem was a mysterious problem involving recursion.
I passed an object recursively to a function - and PHP 4 under
unix behaved very badly - apparently making a copy of the object -
or misbehaving in a very poor fashion. I had to extract the
object from the call chain and put it into a class variable
before things started working again.

As a brief summary: SQL portability between these environments
was apalling - worse than I had expected. PHP portability was
not very good. Significantly worse than something like Java - IMO.

I look forward to the portability situation improving - it seems
as though there is significant scope for improvement.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #1
Share this Question
Share on Google+
24 Replies


P: n/a
> As a brief summary: SQL portability between these environments
was apalling - worse than I had expected. PHP portability was
not very good. Significantly worse than something like Java - IMO.
Well, keep in mind you made two moves: one from Windows to Unix, and the
other from PHP5 to PHP4. Maybe a third move too, since you didn't
mention what version(s) of MySQL you were using.

I routinely write and deploy PHP/MySQL code on both Windows- and
Unix-based servers with no problems or code changes whatsoever. However,
I have never written something for PHP5 then tried to get it running
under PHP4. My guess is: you're going to have problems going that
direction. Without a doubt any major new version is going to introduce
features that aren't supported in prior versions, or modify existing
features, with completely different underlying implementations. For
example, you said:
I passed an object recursively to a function - and PHP 4 under
unix behaved very badly
Which doesn't surprise me, since the entire object model implementation
was re-written for PHP5.
I look forward to the portability situation improving - it seems
as though there is significant scope for improvement.


I don't see how you can ask for improvement. PHP4 is done. You can't
change history. Do you expect them to rewrite PHP4 and re-release it to
work better with PHP5? Or do you expect a new version of PHP5 which
implements poor, inefficient PHP4-like object handling? Just for
portability's sake?

In either case, one or both of your servers will require upgrading. So
if you have to upgrade anyway, might as well make them both PHP5.

--cd
Jul 17 '05 #2

P: n/a
Coder Droid <co********@likethiswouldstopspam.hotmail.com> wrote or quoted:
I look forward to the portability situation improving - it seems
as though there is significant scope for improvement.


I don't see how you can ask for improvement. PHP4 is done. You can't
change history. Do you expect them to rewrite PHP4 and re-release it to
work better with PHP5? Or do you expect a new version of PHP5 which
implements poor, inefficient PHP4-like object handling? Just for
portability's sake?


What I'm hoping for is that PHP 5 doesn't have so many broken bits in
it - which PHP 6 is forced to break backwards compatibility to fix.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #3

P: n/a
Hello,

On 10/19/2004 05:36 PM, Tim Tyler wrote:
As a brief summary: SQL portability between these environments
was apalling - worse than I had expected. PHP portability was
not very good. Significantly worse than something like Java - IMO.


That is because you have not really looked at the existing database
abastraction packages for PHP.

If you want portability, you may want to look at Metabase. Not only it
provides means to write applications without needing to change a single
line to adapt to different databases, but it also provides portable
means to define and install your database schema.

All you need to do is to define your database schema of tables, fields,
indexes and sequences in a simple XML format and Metabase schema manager
classes will install it for you.

Now, what is really wonderful is that if you want to chenage your
database schema, you just need to change the XML schema definition and
Metabase schema manager will figure what were the changes and perform
the necessary alterations without disturbing the data that was already
inserted in the database after the schema was installed for the first
time or updated for the last time.

This is something that I have yet to see in the Java world.

Metabase API also offers other portable features that are very
important for Web development like sequence emulation (database
independent auto-incremented values for primary key fields) and (before)
query result range row limit (like MySQL LIMIT but in database
independent way).

(BTW, did you know that it was PHP author Rasmus Lerdorf that invented
the concept of the LIMIT clause for mini-SQL that was later adopted by
MySQL and others).

These portable features were so innovating when Metabase was started to
be developed in late 1998 that most other PHP database abstraction
packages have copied Metabase. I know there was some progress in the
latest JDBC releases, but AFAIK it seems that JDBC has still some catch
up to do in terms of the reach and utility of database portability
features, especially of interest for Web applications.

Metabase is Open Source is available here:

http://www.phpclasses.org/metabase

--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html
Jul 17 '05 #4

P: n/a
Tim Tyler wrote:
I just ported one of the apps I wrote using PHP 5 under Windows to
PHP 4 under unix.

I knew I wanted to deploy in this environment - and wrote my code in
anticipation of running in the other environment.

A brief summary follows:
(snip) The other problem was a mysterious problem involving recursion.
I passed an object recursively to a function - and PHP 4 under
unix behaved very badly - apparently making a copy of the object -
or misbehaving in a very poor fashion. This is quite normal since by default, PHP4 does not pass objects by ref.
As a brief summary: SQL portability between these environments
was apalling - worse than I had expected. PHP portability was
not very good. Significantly worse than something like Java - IMO.

I look forward to the portability situation improving - it seems
as though there is significant scope for improvement.


Well, why do you think that there was a major version number change
between PHP4 and PHP5 ?

PHP portability is quite good. The problem here is that you just *can't*
hope to run PHP5 code on a PHP5 interpreter, whatever the OS. Would you
seriously expect to run Java 1.5 code on a 1.1 JVM ? And would you
complain about portability if it failed ?

It seems as though there is significant scope for improvement in your
development & deployment process.

My 2 cents
Bruno

Jul 17 '05 #5

P: n/a
> PHP portability is quite good. The problem here is that you just
*can't*
hope to run PHP5 code on a PHP5 interpreter, whatever the OS.


Did you mean "run PHP5 code on a PHP4 interpreter"?

--cd
Jul 17 '05 #6

P: n/a
Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote or quoted:
Tim Tyler wrote:
I just ported one of the apps I wrote using PHP 5 under Windows to
PHP 4 under unix.

I knew I wanted to deploy in this environment - and wrote my code in
anticipation of running in the other environment.

A brief summary follows:

The other problem was a mysterious problem involving recursion.
I passed an object recursively to a function - and PHP 4 under
unix behaved very badly - apparently making a copy of the object -
or misbehaving in a very poor fashion.


This is quite normal since by default, PHP4 does not pass objects by ref.


Bad behaviour :-| I'm glad this was fixed - but sorry it needed fixing.
As a brief summary: SQL portability between these environments
was apalling - worse than I had expected. PHP portability was
not very good. Significantly worse than something like Java - IMO.

I look forward to the portability situation improving - it seems
as though there is significant scope for improvement.


Well, why do you think that there was a major version number change
between PHP4 and PHP5 ?


Maybe because of added features - rather than broken backwards
compatibilty?
PHP portability is quite good. The problem here is that you just *can't*
hope to run PHP5 code on a PHP5 interpreter, whatever the OS.
That problem was mostly that some fairly straightforwards recursion
code failed to work as expected on PHP 4.
Would you seriously expect to run Java 1.5 code on a 1.1 JVM ?
I do that regularly ;-)
It seems as though there is significant scope for improvement in your
development & deployment process.


Great. Thanks for that. I certainly won't be expecting PHP to be
very backwards-compatible again.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #7

P: n/a
Tim Tyler wrote:
PHP portability is quite good. The problem here is that you just can't
hope to run PHP5 code on a PHP5 interpreter, whatever the OS.


That problem was mostly that some fairly straightforwards recursion
code failed to work as expected on PHP 4.


Were you passing objects in the recursive function? If so, perhaps that's
where the problem was as (already mentioned) the default behaviour in PHP4
is to pass objects by reference so you would have been making recursive
copies of the object. Not so bad if there's only a few levels of recursion
but really bad if there dozens or hundreds.

If you need to pass something by reference you can prepend the value with &

This first example ensures no matter what the calling code does, the value
$var will always be passed in by reference.

function foo1(&$var) {
}

This second example passes $var in by reference to the function foo2:

foo2(&$var);

You can also assign the reference of a variable in this way eg:

$a =& $b;
$a = &$b;

Both work the same way; it doesn't seem to matter just where the & is. In
the above example $b is now a reference to $a so

$a =& $b;
$a = 'foo';
print $b;

will print 'foo';

You may have already known all this, but if not now you do :)

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/
Jul 17 '05 #8

P: n/a
Chris Hope wrote:
Were you passing objects in the recursive function? If so, perhaps that's
where the problem was as (already mentioned) the default behaviour in PHP4
is to pass objects by reference


I meant by value....

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/
Jul 17 '05 #9

P: n/a
.oO(Tim Tyler)
I just ported one of the apps I wrote using PHP 5 under Windows to
PHP 4 under unix.
[...]

Portability was not too bad. However there were several problems I did
not anticipate.

One was that MySQL behaved completely differently. It didn't like
the quotes I used. [...]
Didn't it like double quotes around strings? That's probably because
MySQL is running in ANSI mode on that system.
I also had two PHP language problems.

One was that integers I had used as unique IDs in database fields
started showing up as "1.556564658E18" under unix
I've never experienced something like this. What type did you use in the
db? When did they show up in this scientific form?
The other problem was a mysterious problem involving recursion.
I passed an object recursively to a function - and PHP 4 under
unix behaved very badly - apparently making a copy of the object -
PHP5 uses references by default, PHP4 does not.
or misbehaving in a very poor fashion. I had to extract the
object from the call chain and put it into a class variable
before things started working again.
Not really sure what you mean, but for example something like

$foo->doThis()->doThat();

won't work in PHP4.
As a brief summary: SQL portability between these environments
was apalling - worse than I had expected.
I consider it a configuration issue.
PHP portability was
not very good.


It should be. There are only very few parts and extensions that work
differently on certain platforms, most parts should work platform-
independent.

Micha
Jul 17 '05 #10

P: n/a
Michael Fesser <ne*****@gmx.net> wrote or quoted:
.oO(Tim Tyler)

I just ported one of the apps I wrote using PHP 5 under Windows to
PHP 4 under unix.
[...]

Portability was not too bad. However there were several problems I did
not anticipate.

One was that MySQL behaved completely differently. It didn't like
the quotes I used. [...]


Didn't it like double quotes around strings? That's probably because
MySQL is running in ANSI mode on that system.


They /were/ unusual "top-bit-set" quotes.
I also had two PHP language problems.

One was that integers I had used as unique IDs in database fields
started showing up as "1.556564658E18" under unix


I've never experienced something like this. What type did you use in the
db? When did they show up in this scientific form?


The problem was most likely their generation.

They were generated using rand().

The docs for rand say:

"Note: On some platforms (such as Windows) RAND_MAX is only 32768."

- http://uk.php.net/rand

In other words - don't use rand with no arguments in PHP - it's not
portable.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #11

P: n/a
Chris Hope <bl*******@electrictoolbox.com> wrote or quoted:
Tim Tyler wrote:
PHP portability is quite good. The problem here is that you just can't
hope to run PHP5 code on a PHP5 interpreter, whatever the OS.


That problem was mostly that some fairly straightforwards recursion
code failed to work as expected on PHP 4.


Were you passing objects in the recursive function?


Yes.
If so, perhaps that's where the problem was as (already mentioned) the
default behaviour in PHP4 is to pass objects by reference so you would
have been making recursive copies of the object. Not so bad if there's
only a few levels of recursion but really bad if there dozens or
hundreds.


It wasn't a performance problem. Switching from passing by value to
passing by reference is simply not a backwards-compatible change.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #12

P: n/a
> Great. Thanks for that. I certainly won't be expecting PHP to be
very backwards-compatible again.


Correct me if I'm wrong but usualy backward compatibility really means
backward not forward. This mean php5 should run code written for php4. You
cannot ask for forward compatibility so that php5 will later run code for a
version (php6) that doesn't exist yet.
Jul 17 '05 #13

P: n/a
Tim Tyler wrote:
It wasn't a performance problem. Switching from passing by value to
passing by reference is simply not a backwards-compatible change.


You appear to misunderstand the concept of backwards-compatible!

Code written for PHP4 compiler should compile happily with PHP5
compiler. ie the PHP5 compiler is backwards-compatible with code written
for previous compilers.

You have written code for PHP5 compiler: it should *NOT* be expected to
compile with the PHP4 compiler.

in your context, for correct operation under PHP4, one should explicitly
pass objects by reference. If you had written code that way for PHP4,
then it would work properly in PHP5.
PHP5 removes the requirement to explicitly pass by reference.
Jul 17 '05 #14

P: n/a
2metre <2m****@xxxhersham.net> wrote or quoted:
Tim Tyler wrote:
It wasn't a performance problem. Switching from passing by value to
passing by reference is simply not a backwards-compatible change.


You appear to misunderstand the concept of backwards-compatible!


No I don't.

You appear to misunderstand the situation.

To repeat myself, switching from passing by value to passing by reference
is *NOT* a backwards-compatible change.

If you use the default of copy by value - using PHP 4 - and change the new
object that won't make any difference to the original one.

Try that under PHP 5 and the original object will be copied by reference
and then corrupted.

That is different behaviour that might stop programs working as expected.
Code written for PHP4 compiler should compile happily with PHP5
compiler. ie the PHP5 compiler is backwards-compatible with code written
for previous compilers.


PHP is usually interpreted. Your comment thus makes little sense :-|

I've just explained how the change will cause some PHP 4 code to break
under PHP 5.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #15

P: n/a
Daedalus <da*********@hotmail.com> wrote or quoted:
Great. Thanks for that. I certainly won't be expecting PHP to be
very backwards-compatible again.


Correct me if I'm wrong but usualy backward compatibility really means
backward not forward. This mean php5 should run code written for php4.


....and that's clearly not the case under some circumstances. PHP 4 passed
objects by value and PHP 5 passed them by reference. Modify a PHP object
passed by value and the original remains unaffected. Different behaviour
will result if such code is executed on PHP 5.

Switching from passing objects by reference to passing them by value is
*not* a backwards compatible change - for this reason.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #16

P: n/a
Tim Tyler wrote:
2metre <2m****@xxxhersham.net> wrote or quoted: To repeat myself, switching from passing by value to passing by reference
is *NOT* a backwards-compatible change. If you use the default of copy by value - using PHP 4 - and change the new
object that won't make any difference to the original one. The point is that under PHP4 it *didnt* work (properly). If you had
written code that *did* work under PHP4, then under PHP5 it would work too.

Code written for PHP4 compiler..


PHP is usually interpreted. Your comment thus makes little sense :-|

My semantic mistake. For 'compiler' in my last message please read
'interpreter'. (Damn! I hate being inaccurate!)
I've just explained how the change will cause some PHP 4 code to break
under PHP 5.

My reading was that your PHP5 code broke with the PHP4 interpreter.
Jul 17 '05 #17

P: n/a
.oO(Tim Tyler)
Code written for PHP4 compiler should compile happily with PHP5
compiler. ie the PHP5 compiler is backwards-compatible with code written
for previous compilers.


PHP is usually interpreted. Your comment thus makes little sense :-|


The code is compiled to bytecode before execution.

Micha
Jul 17 '05 #18

P: n/a
2metre <2m****@xxxhersham.net> wrote or quoted:
Tim Tyler wrote:
2metre <2m****@xxxhersham.net> wrote or quoted: To repeat myself, switching from passing by value to passing by reference
is *NOT* a backwards-compatible change.

If you use the default of copy by value - using PHP 4 - and change the new
object that won't make any difference to the original one.


The point is that under PHP4 it *didnt* work (properly). If you had
written code that *did* work under PHP4, then under PHP5 it would work too.


I've just explained twice why that statement is not true.

Code written under PHP 4 can break under PHP 5 - due to the change
in the object model that switched from pass-by-value to
pass-by-reference.

No attempt to refute my argument has been made. If you are not able
to produce any sort of criticsim of the argument, you should accept
the conclusion.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #19

P: n/a
> Code written under PHP 4 can break under PHP 5 - due to the change
in the object model that switched from pass-by-value to
pass-by-reference.


Hmmmm.... I haven't had a chance to really dig into PHP5 yet. I did some
cursory glances at the new features when it first came out, but this "by
value" vs "by ref" change is news to me. So let me get this straight. If
I have this code:

$obj = new Object();
$obj->a = 1;
f($obj);
print $obj->a;

....and...

function f($obj) {
$obj->a++;
}

....then this outputs '1' in PHP4 and '2' in PHP5? Is that what I gather
from this discussion?

--cd
Jul 17 '05 #20

P: n/a
Coder Droid wrote:
Code written under PHP 4 can break under PHP 5 - due to the change
in the object model that switched from pass-by-value to
pass-by-reference.


Hmmmm.... I haven't had a chance to really dig into PHP5 yet. I did some
cursory glances at the new features when it first came out, but this "by
value" vs "by ref" change is news to me. So let me get this straight. If
I have this code:

$obj = new Object();
$obj->a = 1;
f($obj);
print $obj->a;

...and...

function f($obj) {
$obj->a++;
}

...then this outputs '1' in PHP4 and '2' in PHP5? Is that what I gather
from this discussion?


You are correct.

However if you do this in PHP4 then it will also output 2:

function f(&$obj) {
$obj->a++;
}

OR:

f(&$obj);

The & in front of the $ ensures the parameter is passed by reference. If you
put it in the function then you don't need to put it in all calls to the
function.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/
Jul 17 '05 #21

P: n/a
> You are correct.

However if you do this in PHP4 then it will also output 2:

function f(&$obj) {
$obj->a++;
}


Yes, of course. But the point remains: unchanged code that behaves one
way in PHP4 can behave completely differently in PHP5, much to the
dismay of the unwary programmer. It's not a question of whether pass by
reference is possible or not, it's the fact that upgrading to PHP5 can
break existing code if you were depending on pass by value in these
instances. I was wondering what TT was getting worked up about, so at
least now I see where he's coming from.

But this is just objects, right? That is, this code:

$a = 1;
print $a;

function($a){
$a++;
}

will print 1 for both PHP4 and PHP5, n'est-ce pas?

Otherwise, *everything* would break. But who knows, maybe everything
breaking is worth it if the new feature packs a big enough payoff. (I
need to just bite the bullet and give PHP5 a whirl...)

--cd
Jul 17 '05 #22

P: n/a
Coder Droid wrote:
You are correct.

However if you do this in PHP4 then it will also output 2:

function f(&$obj) {
$obj->a++;
}


Yes, of course. But the point remains: unchanged code that behaves one
way in PHP4 can behave completely differently in PHP5, much to the
dismay of the unwary programmer. It's not a question of whether pass by
reference is possible or not, it's the fact that upgrading to PHP5 can
break existing code if you were depending on pass by value in these
instances. I was wondering what TT was getting worked up about, so at
least now I see where he's coming from.

But this is just objects, right? That is, this code:

$a = 1;
print $a;

function($a){
$a++;
}

will print 1 for both PHP4 and PHP5, n'est-ce pas?

Otherwise, *everything* would break. But who knows, maybe everything
breaking is worth it if the new feature packs a big enough payoff. (I
need to just bite the bullet and give PHP5 a whirl...)


Yes. Correct. *Everything* in PHP4 is passed by value by default. For some
reason they decided in 5 to make objects be passed by reference by default
(I'm not sure therefore if there's even a way to pass them by value). This
may or may not be the same for arrays as well, which are also passed by
value in 4 - the following example would also print 1.

$a[0] = 1;
foo($a);
print $a[0];

function foo($a) {
$a[0]++;
}

It goes against common sense to some degree to pass arrays and objects by
value which I think may be why they changed it. It probably wasn't the best
decision to make though as it makes the upgrade path a lot harder for
people if they make a habit of passing objects around the place.

I myself do pass objects (usually just a PEAR database object into another
object so you don't need to keep passing connections around the place) but
pass them explicitly by reference using the & operator.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/
Jul 17 '05 #23

P: n/a
Coder Droid <co********@likethiswouldstopspam.hotmail.com> wrote or quoted:
Yes, of course. But the point remains: unchanged code that behaves one
way in PHP4 can behave completely differently in PHP5, much to the
dismay of the unwary programmer. It's not a question of whether pass by
reference is possible or not, it's the fact that upgrading to PHP5 can
break existing code if you were depending on pass by value in these
instances. I was wondering what TT was getting worked up about, so at
least now I see where he's coming from.

But this is just objects, right? That is, this code:

$a = 1;
print $a;

function($a){
$a++;
}

will print 1 for both PHP4 and PHP5, n'est-ce pas?


You mean:

$a = 1;
test($a);
print "LFOO:".$a;

function test($a) {
$a++;
}

Yes: that still prints out 1 in PHP 5.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Jul 17 '05 #24

P: n/a
> You mean:

$a = 1;
test($a);
print "LFOO:".$a;

function test($a) {
$a++;
}
er, yeah. was typing too quickly.
Yes: that still prints out 1 in PHP 5.


Okay.

--cd
Jul 17 '05 #25

This discussion thread is closed

Replies have been disabled for this discussion.