[odb-users] Dynamic Database usage for scripting?

[Rafal Gm]

hm, that dynamic class thing sound all-right, I'm just wondering know,
because ODB will create the table "dynamic_object" for that class, but
would it be possile to use one class for multiple tables? If yes how would
I specify that?


2013/9/9 Boris Kolpackov <boris at codesynthesis.com>

> Hi Rafal,
>
> Rafal Gm <grasmanek94 at gmail.com> writes:
>
> > I would like to bind a scripting language to my application and somehow
> > expose the ODB features.
>
> I think it is useful to distinguish between these two cases:
>
> 1. Exposing an ODB-persistent C++ class(es) to a scripting language. This
>    should be fairly straightforward since, in a nutshell, all ODB does is
>    add database persistence support to a plain C++ class. Though,
> admittedly,
>    things get trickier if you also want to be able to construct and run
>    arbitrary queries from a scripting language (native queries are probably
>    the best option here).
>
> 2. Expose the ODB functionality itself to a scripting language. That is,
>    allow "classes" as defined in a scripting language to be persisted via
>    ODB. This will be a lot harder and it is probably a better idea to use
>    an ORM designed for that scripting language specifically.
>
> It seems to me you are after some variant of #2.
>
>
> > How would I design a class that at the same time works with odb and can
> be
> > used to provide enough dynamic-ality (sorry bad english) for a scripting
> > language? What's compiled is compiled and can't be changed. and a script
> > can always be reloaded, For example the script could use it's own colums
> > which are not in the C++ compiled code.
>
> Well, just one idea: instead of having normal data members, your class
> data could be defined as a set of name-value pairs:
>
> #pragma db object
> class dynamic_object
> {
>   std::map<std::string, std::string> data;
> };
>
> Then the script can do all sorts of "dynamic" things with the data (e.g.,
> add new "columns", discover existing ones, etc).
>
> Boris
>