[odb-users] Concerns/Pitfalls Using ODB in a Library?

[Per Edin]

Hi Brian!

Regarding sessions I think custom sessions would solve the problem,
see Section 11.2 in the manual. I.e. libx would implement its own
session class and use that, instead of odb::session. It might even be
possible to reuse parts of odb::session for this.

The schema_catalog class supports schema names, which would "isolate"
the schema in libX from libY. I haven't tried mixing ODB in libraries
like this myself so maybe you'll run into problems with static
initialization and what not.

Kind regards,
Per Edin


Best regards,

Per Edin
info at peredin.com | https://linkedin.com/in/peredincom | http://peredin.com/


On Wed, Mar 13, 2019 at 1:35 PM Brian Coggins <becoggins at hotmail.com> wrote:
>
> Are there any potential pitfalls to be aware of using ODB in a library whose clients may also be using ODB?
>
> For example, imagine I have a component X which uses ODB to access a SQLite database.  This is built as a static library, libx.a.  This component libx.a would then be linked to several command line tools, one of which, Y, uses ODB to access a MySQL database.
>
> My intention is that the ODB schema for these components will be completely separate, with data passed across an interface that does not expose ODB features.  That is, the ODB pragmas for X are not exposed to the client code at all and the client code will not know about any of X’s uses of ODB, and likewise ODB components from Y are not passed into X.  Thus the ODB compiler invocation for building libx.a will only be aware of X’s schema, while the ODB compiler invocation for building Y will only be aware of Y’s schema.
>
> Of course, when all this is linked together, libodb will see both schema, and ODB instances for both may be active at the same time.  That’s why I’m asking this question of whether there are any potential problems.
>
> One issue I thought of is odb::session, which is thread-specific.  If X needs to use an odb::session, presumably it should do this on a separate thread so that there are no potential conflicts with odb::session instances in Y?  Are there other concerns?  Will odb::schema_catalog handle things correctly if X and Y both invoke it?
>
> Thanks,
> Brian
>
>
>
>
>