Boost logo

Boost :

From: Bohdan (warever_at_[hidden])
Date: 2002-11-20 03:04:13

"Arkadiy Vertleyb" <vertleyb_at_[hidden]> wrote in message
> Bohdan,
> If I understand correctly you have some way to split an object into fields.
> After you do it, what are your fields, strings?

No. Field type is also defineable i.e. int/double/char ...

> If so, this is good enough
> for putting an object in the grid, but we actually try to achieve different
> goals.

Yep. You confirmed my first-look thoughts.

> We are implementing relational algebra -- joins, projections, etc.

With run-time relational libray you also can do joins, projections ..
but without compile-time type safety.

> on relational tables that look like STL containers, and can have columns of
> arbitrary (built-in or user-defined) types. Templates allow us to achieve
> this in a typesafe manner.

I was thinking about some simple variant of rtl::table with predefined
run-time tuple. In this case you can define structure of this tuple
during run-time -> define schema of whole table. But i'm still not
expert in rtl so i can be wrong.

> You are right, we can't dynamically define table schema, this is the price
> for type safety.
> Having said that, I am not sure that RTL is a suitable tool for XML
> serialization or any serialization at all (I maybe wrong, though). In fact
> RTL itself needs to collaborate with a serialization library. We think
> persistence and relational algebra are ortogonal things that are often put
> together because of RDBMS. Since RTL was mentioned in this context, I
> thought I needed to provide certain clarifications.

Dynamic variant of rtl theoretically can avoid only in-memory limitations.
You can inherit from base class (table,index,database,record, nested_table ...)
and supply factory for your platform. Than you can have same interface
for in_memory relational tables and for serious relational database table.

Most probably you are right: rtl and runtime variant have different directions.


Boost list run by bdawes at, gregod at, cpdaniel at, john at