A generic filter invoked immediately after OrmLite creates POCOs

I would like to know if anyone knows of a way to inject a custom fn that gets invoked immediately after the OrmLite creates the relevant POCOs and sets all the fields from the sql query that is being invoked, yet before any caller receives the data from the db.

Similar to the Insert/Update filters that allow you to modify the POCO before insert, I would like to modify the POCO after select. A generic example similar to the Insert/Update IAudit-style filter would be to set a “read from db timestamp” (not that this example represents what I’m looking to do). Almost like the constructor but that gets called after all the fields are set from the SQL result.

This would probably get invoked via either a class attribute or as an interface.

thanks!

There’s no equivalent Select filter that iterates over the populated resultsets, the closest filter available is the generic Exec Filters where you can intercept OrmLite DB API calls.

Had considered the exec filter, but it will require a lot of special-case handling. Was hoping for something that might be injected at the end of PopulateWithSqlReader with something like a [PostPopulate] attribute as a thought.

If that’s not an option, is there a way to ensure a POCO property gets set last via the model definition that gets used in the property cache? Perhaps there’s a way we could fake it that way.

I don’t understand what you mean by this?

When the populate from sql reader is invoked, it builds a cache of fields to assign to the POCO based on the fields available in the data reader, loops through them and calls the setfn for each. If we could ensure a specific field is last in the list, then it might be feasible to get a workaround.
But reading the code for GetIndexFieldsCache it looks like the order of the fields in the array will be based on the order of the reader’s columns.

Will try the exec filter, or see if we can try something custom in the populate loop and propose.

An order dependent index cache is not a fragile constraint OrmLite should be restrained with.

I’ve added OrmLiteConfig.PopulatedObjectFilter in this commit which is available from the latest v5.5.1 that’s now on MyGet.

Although I’m not a fan of adding these random static filters along the hot execution paths at it adds unnecessary static field checks for filters that will rarely ever get used.

Thanks! You’re right that it could be dangerous and should be treated with care. Will give it a try and see how that fits.