[odb-users] Transient class member that is only used to load an expression

[Boris Kolpackov]

Hi Tolga,

Tolga HOŞGÖR <fasdfasdas at gmail.com> writes:

> Thanks for ODB. It is a great, professional project.

Thanks, I am glad you are enjoying it.


> But the thing is I don't want the huge JSON column to be converted to text
> and then parsed by the C++ JSON library completely. I need to add that JSON
> class member to a lazy loading section and use only one field of it most of
> the time. For that I want to create another (kind of a) transient
> std::string class member that loads with 'table.JSON_column->>'json-key'
> expression in the SELECT query field when I load the object. Obviously it
> should not have an actual column on the database side.
>
> Is there a correct way to do this?

There is no direct support for this in ODB. What you are looking
for is an "expression member". While I can see it being useful,
supporting something like this will further complicate the already
complex logic in this area. Also, once we have this support, the
next "reasonable" thing to want would be custom JOIN's so that you
could use joined tables/objects in such expressions...

At the same time, all of this (including custom JOIN's) is already
supported by ODB views. In fact, it would be trivial to implement
an object-loading view that also contains your expression. It will
even load everything with a single SELECT statement. I would say
this is a perfect solution except that this expression is loaded
into a data member outside the object (you would probably be able
to "patch" it directly into the object with a bit of clever code)
and, and this is the biggest issue, you have to load/query the
view, not the object. If you don't mind wrapping the database::load
(and database::query calls, if you use them), then this would
work pretty well. 

Perhaps we should be thinking about supporting something like
loading/querying an object using a custom object-loading view
but using the normal object load/query API. Or perhaps we should
just keep it simple ;-).

Boris