[Feature request] - Multiple columns in alias
Would it be useful (and possible) to allow aliases on multiple columns ?
The first use case coming to my mind being
<object class="Object">
<field key="first_name" dbtype="varchar" precision="50" phptype="string" null="false" default="" />
<field key="last_name" dbtype="varchar" precision="50" phptype="string" null="false" default="" />
<alias key="full_name" field="CONCAT(first_name, ' ', last_name)" />
</object>
It is far too easy to simply do this in the generated class file.
$Object->get FullName(){
return $this->get('first_name') . ' ' . $this->get('last_name);
}
It's an interesting idea, especially where you could save a lot of PHP overhead by having the database do the work. But it seems like the definition of the alias would have to be engine-specific.
Indeed, but schema are already somehow engine specific (we need 1 schema per DB engine/type)... the other problem being : those aliases would need to be read-only (ie. how would we handle $object->set('full_name', 'First Middle Last Or Anything Complex')).
Probably better to close this false "bright idea" ^^
rtripault, I use that technique to hand off status flags without wasting table space on a process which is over in a thousandths of a second.
The interesting thing is I did this:
<index alias="unNeeded" name="unNeeded" primary="false" unique="true" type="BTREE">
<column key="name" length="" collation="A" null="false" />
<column key="stateAbrv" length="" collation="A" null="false" />
<column key="zipCode" length="" collation="A" null="false" />
</index>
<alias key="cityStateZip" field="name,stateAbrv,zipCode" />
Ang xPDO was able to parse it into this:
'fieldAliases' =>
array (
'cityStateZip' => 'name,stateAbrv,zipCode',
),
'indexes' =>
array (
'unNeeded' =>
array (
'alias' => 'unNeeded',
'primary' => false,
'unique' => true,
'type' => 'BTREE',
'columns' =>
array (
'name' =>
array (
'length' => '',
'collation' => 'A',
'null' => false,
),
'stateAbrv' =>
array (
'length' => '',
'collation' => 'A',
'null' => false,
),
'zipCode' =>
array (
'length' => '',
'collation' => 'A',
'null' => false,
),
),
),
),
Bottom line: xPDO can parse it.
But they are not usable as is for the purpose of this feature request. Keeping in mind the outputs are usually scalar, we would have to define a means to define the fields, separators, a output format (etc).
I agree with the read only aspect, but that would defeat the point of the "Alias" element.
Perhaps a new Element will serve this.
I'm consider implementing a dbtype for a field definition that would allow any valid platform-specific SQL expression. I believe that would satisfy this feature more appropriately than changing alias to be more than a shortcut to a different field.