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

[Troy Heron]

I'm using the pre-built .deb ODB compiler on x68_64 Linux.

I completely missed that load() member on the iterator. Thanks, exactly
what I was looking for.


On Tue, Dec 3, 2013 at 4:47 PM, Boris Kolpackov <boris at codesynthesis.com>wrote:

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