[odb-users] any access to sequence without explicitly naming it?

[NIkolai Marchenko]

>  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.

This unfortunately requires too much shuffling of members out of a class
just to persist the initial version of it. it's extremely fragile and
unsustainable.

> Normally you would use a native view for that:

sequence idea ended up not working because odb ignores assigned ids on
persist it will just generate a new one regardless of what I assign. under
the hood it always uses DEFAULT for a key when persisting

> It's safe to cast away const-ness if you need to. Per the documentation:

Arguable. Theoretically, yes, it's safe. Realistically when I see mutable
or const_cast in the code I want to go have words with the author.

In the end I am now creating an empty token object inside the
uuidbase table that I assign as the pointee of the reference, then update
to an actual object in post_persist. Still, it seems like this
functionality needs something less convoluted in ODB

On Mon, Sep 1, 2025 at 5:12 PM Boris Kolpackov <boris at codesynthesis.com>
wrote:

> 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."
>