[odb-users] ODB Postgresql default values

Boris Kolpackov boris at codesynthesis.com
Fri Jul 19 05:23:48 EDT 2013


Hi Mikhail,

Mikhail V. Tomilov <mvtomilov at gmail.com> writes:

> struct Contractor
> {
>      boost::uuids::uuid       contractor_uuid;
>      bool                     hidden;
>      int64                    version;
>      boost::posix_time::ptime created_at;
>      std::string              name;
> };
> 
> Corresponding DB table:
> 
>  contractor_uuid | uuid                     | not null default uuid_generate_v4() 
>  name            | character varying(512)   | not null                            
>  typeid          | character varying(64)    | not null
>  version         | bigint                   | not null default nextval('contractor_version_seq'::regclass) | plain    |
>  hidden          | boolean                  | not null default false
>  created_at      | timestamp with time zone | not null default now()

ODB doesn't yet have generic support for getting database-computed
values in persist() or update() calls.

One way to work around this is to compute the values on the client
side (also off-loads the database server). In your example, you could
calculate the UUID and the timestamp in your code. For hidden you can
just use the 'default' pragma. Version is a bit trickier but what you
seem to be doing is optimistic concurrency. ODB has built-in support
for that (see the manual for details).

If you must calculate all these value on the server, then the only
way I can think of is to pass NULL values in persist (that would make
the database assign to them default values) and then do reload(). You
could also create a view that only pulls computed values from the
database to make it a bit lighter-weight. Finally, you could use
database operation callbacks (e.g., post_perist; again see the
manual for details) to make it all transparent to the users of your
class. That is, the post_persist callback will automatically get the
values from the database and assign them to the data members.

Also, at some point, we will most likely add support for computed
data members so that they are automatically extracted using the
RETURNING clause (we already use it to return the auto-assigned
object ids).

Boris



More information about the odb-users mailing list