[odb-users] Transient class member that is only used to load an
fasdfasdas at gmail.com
Fri May 1 16:20:40 EDT 2015
Thanks for the comprehensive answer. I guess I will keep the current view
approach then. Views work very well for this situation as you say. I also
have to query information if a bidirectional relationship exists or not and
I'd rather do it in the database side using a view instead of looking
through an ordered std::vector in the code. I am not using sessions anyway
so I am not really missing anything by using the views :).
Using an object-loading view with the load/query api idea feels a bit
unnatural, keeping it simple is probably better. ODB is already really
extensive and more features may make it a bit unappealing for starters.
On Fri, May 1, 2015 at 7:36 PM Boris Kolpackov <boris at codesynthesis.com>
> 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
> > and then parsed by the C++ JSON library completely. I need to add that
> > class member to a lazy loading section and use only one field of it most
> > 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 ;-).
More information about the odb-users