[odb-users] Retrieving Results from Native Queries without Compile-time Fixed Classes

[ATSDB]

Thank you for your reply, please find my comments below.

On 03.02.20 15:14, Boris Kolpackov wrote:
> ATSDB <atsdb at gmx.at> writes:
>
>> The short question is: I would like to use native queries to obtain
>> partial data (some columns of many) from existing (unmapped) tables
>> without having to have compile-time fixed classes to hold the results.
>> Is this possible?
> While it should be possible using implementation details (basically
> what the generated code is using), this is not a documented API, there
> are no stability guarantees, etc. You will also have to write this
> code for each database that you want to support.
>
> Here is, for example, select_statement for SQLite:
>
> https://git.codesynthesis.com/cgit/odb/libodb-sqlite/tree/odb/sqlite/statement.hxx#n210
>
Understood, I'll take a look. Since I only support 2 database systems now (MySQL, SQLite3) this would not be an issue.


>>  From my understanding this is somewhat supported using Views (as stated
>> in the odb manual), but only if I write result classes that store the
>> selected columns - which is then compile-time fixed. Is my understanding
>> correct?
> It is.

Thanks.


>> Background: My applications stores large amounts of data in a database
>> (gigabytes). I wrote a (simplistic) system which allows data abstraction
>> from the actual database schema based on configuration. During loading, the
>> current schema is used to dynamically create the select queries with
>> not-fixed number/names of columns, and the result is stored in custom
>> container (basically a dynamic templated aggregations of std::vectors -
>> think array of structs with dynamic amount of members).
> I assume the types of these columns are not known at compile time either?

No. Whether this was a good choice can be discussed, but this is the way I need it for now.


>> Would it be possible/reasonable to use mapped classes and additionally
>> directly use the native database connections to retrieve the results
>> to fill my custom containers?
> I think it would be reasonable if you don't have a better alternative.
> One thing going for ODB here (IMO), is that the database runtimes are
> pretty efficient and well-tested.

Understood. Well the ODB database code is definitely better than mine :-) and the special "partial load" is one circumstance that ODB was not written
for. But for the smaller-data classes (which I will need more of in the future) and their mapping I could very much benefit from your good work.


Thanks again for your quick and helpful reply, I'll send a notification to the project if I decide to go for it.