How to make the resultset models be upcast to a more specific type?

I need to upcast models to a specific type from a general one. I have a Markup model and Note and Tag inherit from this. I want to be able to do call Markup::find and have it return both Notes and Tags. Sometimes though I will want to only get Notes or Tags with Note::find to be more specific. I need to detect a field to see which type of model it is before creating it as that.

I'm thinking that if the Model class had a static function that would return the type of model to create based upon the data from the database then it would accomplish what I'm trying to do. If that static function was missing then it would use the class name itself.

So it would be great if my Markup class had a static method that looked for the type field from the database result row and then was able to return model class names as it saw fit. This would allow me to call BaseClass::find to return types that inherit it.

If you've got small resultsets, you can overwrite Markup::find() to iterate through the retrieved resultset and build a new result set with the appropriate models.

If you've got big resultsets and don't want to retrieve all the records at once, you can do what I've done and give the Markup class a getOfType() method that returns a new Note or Tag object based on the properties retrieved for the Markup object.

Thanks. That is a pretty nice solution. Basically, in my project all user data goes into a single table. I suppose that if I created a new namespace for the classes to be used in this way then I wouldn't have to explicitly list each of the classes in that getoftype() method.

So do you manually pass in each attribute on an assign in the (kind of) getOfType() factory?

Also does Phalcon treat a model that was pulled from the database differently than a model that had its values assigned in user code? Do I need to pass any flags in?

I suppose that special attention would need to be given to ensure that hooks run at the appropriate level. I never want a model to be able to insert, delete or update at a lower class level if it hasn't been instantiated as that type. Have you figured out a solution to that puzzle?

Also, I suppose that I'd optimize the base class so that it doesn't do snapshots and any other thing that would take up more resources. I don't need to take up 4x the memory.

Hmm, what about assigning values by reference? Would that get me into trouble? I'm considering always using the Resultset wrapper and hiding the base model records behind it and reusing their variables by assigning them by reference to the objects create with getoftype().

This doesn't trigger the afterFetch() hook on the newly typed object. That's not a big deal for me though because in my case, the typed classes interact with the database identically to each other. So, the database interactivity behaviour defined in BasePage applies to all the typed classes as well.

You can see the code converts a Resultset into an array. This will cause you to lose the ability to delete() or update() en masse. I haven't looked into it, but there's bound to be a way to build a new Resultset object rather than an array.

I haven't looked into it, but there's bound to be a way to build a new Resultset object rather than an array.

I was just looking at some Zephir code today and it appears that Phalcon isn't currently built to handle these edge cases and that a lot of things like the query builder would need to be extended. I'm not sure that I feel comfortable with that.

This doesn't trigger the afterFetch() hook on the newly typed object. That's not a big deal for me though because in my case, the typed classes interact with the database identically to each other. So, the database interactivity behaviour defined in BasePage applies to all the typed classes as well.

That's fine. When you call save() on these typed objects, all the necessary beforeSave(), afterSave() etc methods will still be called. These are fully fledged instances of the typed classes, so all the appropriate hooks will be called for those 3 actions. I specifically mentioned afterFetch() because these typed objects aren't "fetched".

My table and user data is capable of building and searching for an inheritance chain (with the MySQL dialect class for FULLTEXT support and soon to be newer MariaDB stuff) and I'd like to be able to call from the more specific type like File::find, Doc::find, Markup::find, Note::find, etc. So I just have to check in the find method as to which current class the type is and then to work down the inheritance tree. Hell, I might end up doing it in third normal form but I'm to get there is the same method.

I really like your approach here because it frees me from the tyranny of the Resultset object. So I suppose that the Resultset class is never meant to be anything more than a nice form to receive data in. It sure would be nice to be able to pass in a lambda to have the query return types based on an evaluation of the DB record data though.

The trouble with a lambda like that is it would have to be run over every record as it was pulled out. That would cause chaos for thinks like the ArrayIterator interface it implements, and the count() function.