Have seen this references as "non_column" in a post or two, but can find any specific documentation or in the orm package code, using fuel 1.4. One reference is here:
Trying to add "virtual" properties to my models. A couple examples would be:
1) have a calculated type field like "name" where its a combo of first_name and last_name set in a observer after retrieve
2) joining in some columns from a has_one relationship where the parent model stores the id reference and the name property would be a "virtual" reference.
Ok, thanks for the heads up, had seen comments from while back that it was in 1.4 develop so was hoping it made it into the release and I was just missing something
Will have a look at the 1.5 develop codebase, and try to follow suit w/ some workable implementation in my codebase
} That seems to just grab all the properties, set them. Then in looking at the model.php __construct() it seems to just loop over all the properties and set them to the appropriate cached/other variable locations.
So if you do $model->someproperty, the model will first check if it's a property (a column). If not, it will check if it's a defined relation. If not, it will create a virtual property for you.
And no, you can't create this type of property through the constructor, you'll have to use the getters/setters for this feature.
Went back through and diffed the whole ORM 1.4 vs 1.5/develop. The only diff in model.php seems to be couple exception changes and the from_array() population where you can now pass in related objects and have them populated.
Only other diffs appear to be in all the relation files, changes to the get() methods where change to using 'query' instead of 'find' call
Any suggestions on where to find this?
Side note.., Model_Soft is awesome, I have some deleted functionality I had to add since all my models are "soft" in nature, can wait to include this.
Then I made a mistake, and the change did make the 1.4 release. ;-)
As I said, the functionality is in the getter/setter (__get/__set), where it stores the data in the _custom_data structure if it's not a property or a relation.
It might be possible to alter the constructor to use this too, but we have to be very careful, since its also used by the DB class as_object() method, where PHP will call the constructor internally with a fixed format to create object instances. That feature may not break.
Ok, was thinking there was a built in mechanism in the way you could define properties. Since this is the case I will mess around with extending the property def then and add some stuff such that it will do some set() calls on these "virtual" columns in my after_retrieve observer
Once I play around with it some, will see how things work and file any appropriate issue/feature-requests
Donate
