[odb-users] Problems with foreign key constraints when erasing

[Boris Kolpackov]

Hi Troy,

Troy Heron <troy.heron at hixxy.org> writes:

> I am using the most recent package from the website

Are you using a pre-built binary for the ODB compiler, a .deb
package, or .rpm? Also which platform (Linux, Windows, etc.),
and architecture (i686, x86_64, etc)?

I will need to build you one for the beta-testing.


> Initially I was planning on using the object's 'name' as the primary key,
> but my application requires that this no be static (objects can be
> renamed). It seems that this would not be possible with foreign key
> constraints. So... I've changed all the objects to have a separate id field
> as primary key and made the name a unique constraint instead. Now I'm
> having troubles with using load() as at the time of loading an object, I
> know the name, not the id. Of course, I could query for the object, but
> that doesn't return a shared_ptr like load does.
> 
> Any idea what the best way to deal with this situation is? I need a primary
> key that can change without breaking foreign key constraints or to be able
> to load using a field other than the primary key.

Having a separate id (probably auto) makes sense. What you are missing
is the fact that you can load the object from the query result iterator:

auto r = db->query<object>(query<object>::name == name);
shared_ptr<object> o = r.begin ().load ();

This is discussed in Section 4.4, "Query Result".

Also, if you are concerned with performance of this approach (compared
to database::load()), then you may want to consider preparing and
caching the query (Section 4.5, "Prepared Queries"). This way it will
be as efficient as database::load().

Boris