mysql_fetch_object mystery (php5)

[jwopitz]

Hi, folks.

 

I am rather new to PHP. I am creating an application where I am using AMFPHP, Flex and MySQL.  On one of my php methods I am trying to return a value object or a mysql query.

return mysql_fetch_object($result);

 

This returns a simple object with the properties of the object set to that data retrieved in the database (as expected). However I want to be able to do this:

return mysql_fetch_object($result, "UserVO"); 

 

When doing so it returns the expected object type (a UserVO), however it returns the values of the UserVO to their initialized values which are various strings. It is not setting the values of the properties to that which are found in the database.

 

Here is my UserVO php class:

<?php
class UserVO
{
    var $_explicitType = "UserVO";
    
    var $id = 0;
    var $userName = 'userName';
    var $password = 'password';
}
?>

What am I missing here? Again I am a complete PHP noob.

[jwopitz]

I just noticed I placed this in the OOP subforum.  It should just be in the general PHP help forum.  If an admin could move this, that would be great. 

 

Thanks,

Justin

[PFMaBiSmAd]

mysql_fetch_object — Fetches a result row as an object. It does not fetch an object.

 

A php object has no meaning to a database. To store a php object in a database you would need to serialize the object before inserting it into a database and unserialize it after it is retrieved from the database.

[trq]

mysql_fetch_object — Fetches a result row as an object. It does not fetch an object.

 

But it can fetch an object of a certain type if specified.

 

I think your actual problem is the fact that you are overiding the properties which would be set by the result from your query. Leave the properties out of the class definition all together and you should be fine.

[jwopitz]

I have a fuzzy understanding of what you are saying Thorpe.  I mod'd the function again so that it would 'cast' the fetched object to a UserVO like so:

return mysql_fetch_object($result, "UserVO");

 

...and I tried leaving the props out of the UserVO class like so:

<?php
class UserVO
{
var $_explicitType = "UserVO";

/*var $id = 0;
var $userName = '';
var $password = '';*/
}
?>

 

...which still results in an object that comes back as the correct type (UserVO) but whose values are null.  So maybe I am thinking in a completely different way than PHP will allow for.  I come from a Flex/ActionScript background.  Here is what I am trying to accomplish in a very high level description:

 

- I send a username and password from Flex to a PHP function

- my expected response from PHP to Flex is a UserVO (using remoting via AMFPHP btw).

- PHP retrieves an object via the mysql_fetch_object and needs to be able to construct a UserVO (php version based on the row data form that mysql request)

- PHP sends Flex the UserVO which translates w/ no massaging of data on Flex side via AMFPHP

 

Is this doable?  I had the expectations that PHP would be able to do this.  Can I take a simple object and cast it the UserVO class? 

 

Thanks for the help thus far.

Justin

[jwopitz]

Ok so I figured out what the issue was.  My MySQL db collation was using UTF8_unicode_ci which means it was trying to assign the value of 'username' in the DB to the property 'username' instead of 'userName' on the UserVO.php which doesn't exist.  So that issue is fixed.

 

However it creates another issue for me which is this.  I am rather inexperienced in working with PHP and MySQL.  I really would not want to massage the data coming out of MySQL or coming out of PHP.  As a Flex developer, I need the ability to have case-sensitive properties stored on the DB.  Actually I need to have my columns in my tables to be case-sensitive in order to reduce/eliminate the massaging of data.

 

What would be the best approach to having my case-sensitive data and column names preserved.  Collations suggestions?

 

Also, in doing some research, I have read that there are some issues with using the bin and cs collations in returning sorted data.  I am sure at some point this will become an issue.  What I haven't been able to discern is if this issue is present in MySQL 5.0.41 which I am using with MAMP for Mac.

 

Again, thanks for the help.