[odb-users] any access to sequence without explicitly naming it?
Boris Kolpackov
boris at codesynthesis.com
Mon Sep 1 10:12:39 EDT 2025
NIkolai Marchenko <enmarantispam at gmail.com> writes:
> suppose an object contains another object. an inner objects points_to the
> outer object with on delete cascade option and both are not persistent yet.
> The objects both have auto id quint64 keys. Since they both don't have id
> yet, I cannot assign an id to points_to and when I persist the _outer_
> object it says that inner isn't persistent yet. but when I persist an
> _inner_ object it also fails because foreign key constraint is not
> satisfied. the schema is created with deferred constraint checking ... but
> I they need to have matching ids beforehand.
One way to resolve this is to use NULL: persist the first object with
a NULL pointer to the second, the second -- with its id, and finally
update the first with the second's (now known) id.
> The only way I see of breaking this loop is to access a sequence for the
> outer object inisde the transaction and reserving the key to it that I can
> feed into points_to... but as far as I can see odb doesn't have a native
> function to access a sequence. This means I have to .execute("raw sql
> here") and this is potentially breaking on refactors.
Normally you would use a native view for that:
https://www.codesynthesis.com/products/odb/doc/manual.xhtml#10.6
You could probably get both ids with a single query as an optimization.
> It's further compounded by the fact that pre-persist callbacks are const
> only.
It's safe to cast away const-ness if you need to. Per the documentation:
"If you need to modify the object in one of the "const" events, then you can
safely cast away const-ness using the const_cast operator if you know that
none of the objects will be created const. Alternatively, if you cannot make
this assumption, then you can declare the data members you wish to modify as
mutable."
More information about the odb-users
mailing list