|
Friday 23 February 2007 2:45:17 pm
Hi Nathan
To me it looks like you misunderstood the ezpersistantobject class a bit, so I try to explain. Please note that this refers to your first post, as I am not exactly sure what you want to achive with the two tables in your last post.
Your definition:
function &definition() {
return array( 'fields' => array(
'myObjectID' => array(
'name' => 'myObjectID',
'datatype' => 'integer',
'default' => 0,
'required' => true
),
),
'keys' => array( 'myObjectID' ),
'function_attributes' => array(),
'class_name' => 'myclass',
'name' => 'myTable'
);
}
The entry 'fields' describes the structure of the table in your database. You have a column that is named myObjectID, is of type integer and is required (which afaik means that eZ will put the default there inan insert query if you don't specify anything). By the way the key 'myObjectID' refers to the name of the column, the entry 'name' => 'myObjectID' refers to the name of the object member variable. They are not required to be the same.
The entry 'keys' means that myObjectID is the identifier for each row, which means that it must be unique. Therefore Bruce's comment that this column must be distinct/unique as otherwise you might get unexpected problems with the database interface. And if it is unique, then you don't need to make a 'DISTINCT' query on this column. So you should rethink your class/table layout.
For completeness's sake:
The entry 'function_attributes' is not necessary if you don't need it. Generally this is meant for having additional object member variables (which will be the keys in the array) whose values does not come from the table row but are computed with a function (whose names are used as values in the array)
The entry 'class_name' is the name of the class that is instantiated with the values from the fetched table row.
The entry 'name' is the name of the table in the database. Ok, now to your query. First of all: http://issues.ez.no/8448 states that select distinct is not supported yet. Depending on your needs the following might still be interesting: As said before making a distinct query on your unique key does not make much sense. There let's assume that your table has an additional row, lets call it 'testRow' which you want to fetch using distinct. So your definition would look like this:
function &definition() {
return array( 'fields' => array(
'myObjectID' => array(
'name' => 'myObjectID',
'datatype' => 'integer',
'default' => 0,
'required' => true
),
'testRow' => array(
'name' => 'testRow',
'datatype' => 'integer',
'default' => '',
'required' => false
),
),
'keys' => array( 'myObjectID' ),
'class_name' => 'myclass',
'name' => 'myTable'
);
}
Now you want to make a distinct query on testRow. Bruce's approach should work fine (although I haven't tested it either, so please report the results):
function fetchDistinctTestRow()
{
$fieldsToFetch = array(); //no other fields to fetch except testRow whis is specified later on
$conditions = null; //we don't have any WHERE conditions
$sortingInfo = null; //no sort on the result
$limitInfo = null; //no limit on result
$asObject = true; //if true it will return an array of objects of class myclass, else an array of arrays
$customFields = array( array( 'operation' => 'DISTINCT testRow',
'name' => 'testRow' ) );
return myclass::fetchObjectList(myclass:definition(),
$fieldsToFetch,
$conditions,
$sortingInfo,
$limitInfo,
$asObject,
$customFields);
} The problem is that this fetches only the colum testRow, not the entire row. This means that any instantiated objects hold only the default values in the member variables except for testRow which is the current value. The only way I see to fetch the entire row is to group by all fields which is a bit cumbersome, but should work at least in MySQL. Maybe I'll try it over the weekend, now it definitely to late... Claudia
|
