From boris at codesynthesis.com Mon Sep 1 10:12:39 2025 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 1 10:12:50 2025 Subject: [odb-users] any access to sequence without explicitly naming it? In-Reply-To: References: Message-ID: NIkolai Marchenko 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." From enmarantispam at gmail.com Mon Sep 1 10:34:23 2025 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue Sep 2 10:11:12 2025 Subject: [odb-users] any access to sequence without explicitly naming it? In-Reply-To: References: Message-ID: > 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 wrote: > NIkolai Marchenko 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." > From finjulhich at gmail.com Fri Sep 12 11:17:28 2025 From: finjulhich at gmail.com (MM) Date: Fri Sep 12 11:18:03 2025 Subject: [odb-users] callback specifier to point to standalone free function instead of member Message-ID: Hello, As part of my use of ODB, I generally managed to keep it hidden from my application objects. Headers that use ODB pragmas exist in different directories, compilation of odb files is separated (though dependent). If 1 day I decide to forgo persistence entirely, the lift should be light. I use callbacks however, and at the moment, the specifier can point to a member function of the class. I've made a request before to have it point to a free standalone function which then lets do the needful inside the odb directories to keep separation clean. Is that doable? Rds, MM From boris at codesynthesis.com Tue Sep 16 01:06:59 2025 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Sep 16 01:07:12 2025 Subject: [odb-users] callback specifier to point to standalone free function instead of member In-Reply-To: References: Message-ID: MM writes: > I use callbacks however, and at the moment, the specifier can point to a > member function of the class. > > I've made a request before to have it point to a free > standalone function which then lets do the needful inside the odb > directories to keep separation clean. > Is that doable? It should be doable but I haven't looked into this in detail yet. This feature is tracked in this issue: https://github.com/codesynthesis-com/odb/issues/1 From enmarantispam at gmail.com Sat Sep 20 16:36:56 2025 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Mon Sep 22 06:14:49 2025 Subject: [odb-users] is on_delete kinda useless or is it me? Message-ID: Whether it is attached to actual full pointer member or to a points_to id it will only delete the most derived data in the table of the class it is declared it. The earlier polymorphic table records are unaffected which means a lot of dead garbage is left in those. If so - what's the point?