From shprotello at mail.ru  Sat Sep 12 01:38:20 2020
From: shprotello at mail.ru (=?UTF-8?B?0KHQtdGA0LPQtdC5INCd0LjQutC+0L3QvtCy?=)
Date: Sat Sep 12 01:55:55 2020
Subject: [odb-users] polymorphic base orphans
Message-ID: <1599889100.356132420@f143.i.mail.ru>


Hi everybody,
?
I encountered a problem concerned with appearing ?orphan??records in the database representing base entities of a polymorphic hierarchy. An example below demonstrates the issue. There are a polymorphic abstract base class with two derived classes one of which contains a pointer to another.
?
#pragma db object abstract polymorphic
struct base
{
? virtual ~base() {}
#pragma db id auto
? int id;
};
#pragma db object
struct derived1
? : public base
{
#pragma db null
? int value;
};
#pragma db object
struct derived2
? : public base
{
#pragma db null
? int value;
#pragma db null on_delete(cascade)
? std::shared_ptr<derived1> ref;
};
?
After persisting objects like this:
?
? ? auto d1 = std::make_shared<derived1>();
? ? db.persist(d1);
? ? auto d2 = std::make_shared<derived2>();
? ? d2->ref = d1;
? ? db.persist(d2);
?
lets delete ?d1? instance:
?
? ? db.erase<base>(d1->id);
?
After committing the database will contain an orphan record:
? ?id?? ?typeid
? ?----------------
? ?2?? ?derived2
?
When I try to resolve the issue by?manually deleting ?base? instance in a database?trigger I receive an exception from ODB.
Is there any reasonable way how to deal with this (quite typical in my opinion) situation in general?
?
Thank you in advance,
Sergey
?
?
From boris at codesynthesis.com  Mon Sep 14 07:48:43 2020
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Sep 14 08:06:19 2020
Subject: [odb-users] polymorphic base orphans
In-Reply-To: <1599889100.356132420@f143.i.mail.ru>
References: <1599889100.356132420@f143.i.mail.ru>
Message-ID: <boris.20200914133603@codesynthesis.com>

?????? ??????? <shprotello@mail.ru> writes:

> #pragma db object abstract polymorphic
> struct base
> {
>   virtual ~base() {}
> #pragma db id auto
>   int id;
> };
> #pragma db object
> struct derived1
>   : public base
> {
> #pragma db null
>   int value;
> };
> #pragma db object
> struct derived2
>   : public base
> {
> #pragma db null
>   int value;
> #pragma db null on_delete(cascade)
>   std::shared_ptr<derived1> ref;
> };

The generated database schema for this object model (using PosgreSQL as
an example):

CREATE TABLE "base" (
  "id" SERIAL NOT NULL PRIMARY KEY,
  "typeid" TEXT NOT NULL);

CREATE TABLE "derived1" (
  "id" INTEGER NOT NULL PRIMARY KEY,
  "value" INTEGER NULL,
  CONSTRAINT "id_fk"
    FOREIGN KEY ("id")
    REFERENCES "base" ("id")
    ON DELETE CASCADE);

CREATE TABLE "derived2" (
  "id" INTEGER NOT NULL PRIMARY KEY,
  "value" INTEGER NULL,
  "ref" INTEGER NULL,
  CONSTRAINT "id_fk"
    FOREIGN KEY ("id")
    REFERENCES "base" ("id")
    ON DELETE CASCADE,
  CONSTRAINT "ref_fk"
    FOREIGN KEY ("ref")
    REFERENCES "derived1" ("id")
    ON DELETE CASCADE
    INITIALLY DEFERRED);


> After persisting objects like this:
>  
>     auto d1 = std::make_shared<derived1>();
>     db.persist(d1);
>     auto d2 = std::make_shared<derived2>();
>     d2->ref = d1;
>     db.persist(d2);
>  
> lets delete ?d1? instance:
>  
>     db.erase<base>(d1->id);
>  
> After committing the database will contain an orphan record:
>    id    typeid
>    ----------------
>    2    derived2

Yes, this is the base entry of d2. When you erased d1, d2 is also erased
due to the derived2::ref reference that has ON DELETE CASCADE. But ON
DELETE CASCADE between base and derived2 points the the "wrong" (for
this case) direction. I don't think there can be a perfect solution to
this issue without breaking everything else. As the manual states, ODB
is not aware of ON DELETE actions that happen at the database level and
thus there are limitations.

I can see two ways to work around this issue:

1. Change std::shared_ptr<derived1> to std::shared_ptr<base> so that the
   generated ON DELETE CASCADE points in the right direction.

   With a bit of virtual member magic you can probably even keep derived1
   in the interface and only present base to ODB.

2. Change on_delete(cascade) to on_delete(set_null) and then erase
   derived2 entries with NULL ref via an ODB call (so that it can do
   the right thing with regards to base/derived).

From rccraigb at gmail.com  Wed Sep 16 14:09:04 2020
From: rccraigb at gmail.com (Craig Burton)
Date: Wed Sep 16 14:27:03 2020
Subject: [odb-users] 'unordered_set' is not a member of 'std'
Message-ID: <CALWbUmkYBB3kpgWSCnYmRcru2bAksv7zo6NKEE8SLRPUuRB7Hg@mail.gmail.com>

Hi,

I'm attempting to use c++14, but have encountered the error below while
invoking the odb compiler.  I went back and recompiled all of the odb
libraries (core, mysql and boost) using the c++14 standard, but it didn't
matter.  I surely must be doing something wrong.  Any thoughts?

Thank you,
Craig


/usr/local/odb-2.4.0/bin/odb --std c++14  --database mysql
--generate-schema --generate-query --profile boost/date-time
--generate-session --default-pointer std::tr1::shared_ptr --at-once
--input-name Depot -I/usr/include -I/usr/local/boost_1_62_0
-I/usr/local/boost_1_62_0/boost/tr1/tr1 (bunch of include files here)
In file included from /usr/local/include/odb/container-traits.hxx:217:0,
                 from <standard-odb-epilogue>:9:
/usr/local/include/odb/std-unordered-set-traits.hxx: At global scope:
/usr/local/include/odb/std-unordered-set-traits.hxx:18:34: error:
?unordered_set? is not a member of ?std?
   class access::container_traits<std::unordered_set<V, H, P, A>>
                                  ^
/usr/local/include/odb/std-unordered-set-traits.hxx:18:34: note: suggested
alternatives:
In file included from
/usr/local/boost_1_62_0/boost/unordered/detail/set.hpp:6:0,
                 from
/usr/local/boost_1_62_0/boost/unordered/unordered_set.hpp:17,
                 from /usr/local/boost_1_62_0/boost/unordered_set.hpp:17,
                 from
/usr/local/boost_1_62_0/boost/tr1/unordered_set.hpp:21,
                 from
/usr/local/boost_1_62_0/boost/tr1/tr1/unordered_set:28,
                 from
/usr/local/include/odb/std-unordered-set-traits.hxx:11,
                 from /usr/local/include/odb/container-traits.hxx:217,
                 from <standard-odb-epilogue>:9:
/usr/local/boost_1_62_0/boost/unordered/unordered_set_fwd.hpp:27:15: note:
  ?boost::unordered::unordered_set?
         class unordered_set;
               ^
<end>
From rccraigb at gmail.com  Wed Sep 16 20:27:09 2020
From: rccraigb at gmail.com (Craig Burton)
Date: Wed Sep 16 20:45:09 2020
Subject: [odb-users] Re: 'unordered_set' is not a member of 'std'
In-Reply-To: <CALWbUmkYBB3kpgWSCnYmRcru2bAksv7zo6NKEE8SLRPUuRB7Hg@mail.gmail.com>
References: <CALWbUmkYBB3kpgWSCnYmRcru2bAksv7zo6NKEE8SLRPUuRB7Hg@mail.gmail.com>
Message-ID: <CALWbUm=BS4RL2sa+1O=xGG6aWoUKJe224GU=RCMnJZS+yOVLdQ@mail.gmail.com>

Quick followup:  after reviewing the ODB documentation, I realized that
c++11 is the supported standard.  I went back and rebuilt all libraries and
my own code using c++11 and I still encounter the same problem.

Craig


On Wed, Sep 16, 2020 at 11:09 AM Craig Burton <rccraigb@gmail.com> wrote:

> Hi,
>
> I'm attempting to use c++14, but have encountered the error below while
> invoking the odb compiler.  I went back and recompiled all of the odb
> libraries (core, mysql and boost) using the c++14 standard, but it didn't
> matter.  I surely must be doing something wrong.  Any thoughts?
>
> Thank you,
> Craig
>
>
> /usr/local/odb-2.4.0/bin/odb --std c++14  --database mysql
> --generate-schema --generate-query --profile boost/date-time
> --generate-session --default-pointer std::tr1::shared_ptr --at-once
> --input-name Depot -I/usr/include -I/usr/local/boost_1_62_0
> -I/usr/local/boost_1_62_0/boost/tr1/tr1 (bunch of include files here)
> In file included from /usr/local/include/odb/container-traits.hxx:217:0,
>                  from <standard-odb-epilogue>:9:
> /usr/local/include/odb/std-unordered-set-traits.hxx: At global scope:
> /usr/local/include/odb/std-unordered-set-traits.hxx:18:34: error:
> ?unordered_set? is not a member of ?std?
>    class access::container_traits<std::unordered_set<V, H, P, A>>
>                                   ^
> /usr/local/include/odb/std-unordered-set-traits.hxx:18:34: note: suggested
> alternatives:
> In file included from
> /usr/local/boost_1_62_0/boost/unordered/detail/set.hpp:6:0,
>                  from
> /usr/local/boost_1_62_0/boost/unordered/unordered_set.hpp:17,
>                  from /usr/local/boost_1_62_0/boost/unordered_set.hpp:17,
>                  from
> /usr/local/boost_1_62_0/boost/tr1/unordered_set.hpp:21,
>                  from
> /usr/local/boost_1_62_0/boost/tr1/tr1/unordered_set:28,
>                  from
> /usr/local/include/odb/std-unordered-set-traits.hxx:11,
>                  from /usr/local/include/odb/container-traits.hxx:217,
>                  from <standard-odb-epilogue>:9:
> /usr/local/boost_1_62_0/boost/unordered/unordered_set_fwd.hpp:27:15: note:
>   ?boost::unordered::unordered_set?
>          class unordered_set;
>                ^
> <end>
>
>
>
From boris at codesynthesis.com  Thu Sep 17 07:55:10 2020
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Sep 17 08:12:53 2020
Subject: [odb-users] 'unordered_set' is not a member of 'std'
In-Reply-To: <CALWbUmkYBB3kpgWSCnYmRcru2bAksv7zo6NKEE8SLRPUuRB7Hg@mail.gmail.com>
References: <CALWbUmkYBB3kpgWSCnYmRcru2bAksv7zo6NKEE8SLRPUuRB7Hg@mail.gmail.com>
Message-ID: <boris.20200917134848@codesynthesis.com>

Craig Burton <rccraigb@gmail.com> writes:

> /usr/local/odb-2.4.0/bin/odb --std c++14  --database mysql
> --generate-schema --generate-query --profile boost/date-time
> --generate-session --default-pointer std::tr1::shared_ptr

My guess would be there is some interference from Boost TR1 (that
whole TR1 support injection is quite hacky). Seeing that you are
using C++14, I would suggest using --default-pointer std::shared_ptr.
I would also suggest upgrading[1] to the latest 2.5.0 pre-release
since we've cleaned up some of that TR1 stuff since 2.4.0.

[1] https://codesynthesis.com/products/odb/doc/install-build2.xhtml

From thutop.dorje at gmail.com  Tue Sep 22 05:02:31 2020
From: thutop.dorje at gmail.com (Thutop Dorje)
Date: Tue Sep 22 09:19:37 2020
Subject: [odb-users] Failed to build ODB compiler 2.4
Message-ID: <CAPGK+2RiJZ2oOW2RfCmdSEWSjGAXRdmxyQ9eamiLG7k69KCbPw@mail.gmail.com>

Hi,

I'm trying to build the ODB compile (version 2.4) with gcc 10 but get a lot
of errors. I read somewhere in this mailing list that the ODB compiler's
code should be adapted to every new major version of gcc.

My question is, what is the most recent version of gcc I should use without
having to adapt the ODB compiler's code ?

Thanks,
Thutop
From boris at codesynthesis.com  Tue Sep 22 09:04:50 2020
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Sep 22 09:22:49 2020
Subject: [odb-users] Failed to build ODB compiler 2.4
In-Reply-To: <CAPGK+2RiJZ2oOW2RfCmdSEWSjGAXRdmxyQ9eamiLG7k69KCbPw@mail.gmail.com>
References: <CAPGK+2RiJZ2oOW2RfCmdSEWSjGAXRdmxyQ9eamiLG7k69KCbPw@mail.gmail.com>
Message-ID: <boris.20200922150251@codesynthesis.com>

Thutop Dorje <thutop.dorje@gmail.com> writes:

> I'm trying to build the ODB compile (version 2.4) with gcc 10 but get a lot
> of errors. I read somewhere in this mailing list that the ODB compiler's
> code should be adapted to every new major version of gcc.
> 
> My question is, what is the most recent version of gcc I should use without
> having to adapt the ODB compiler's code ?

The latest ODB pre-release is compatible[1] with GCC 10 so I would suggest
switching to that. The new build instructions are here:

https://codesynthesis.com/products/odb/doc/install-build2.xhtml

[1] https://www.codesynthesis.com/pipermail/odb-users/2020-July/004538.html

From rccraigb at gmail.com  Thu Sep 24 14:34:01 2020
From: rccraigb at gmail.com (Craig Burton)
Date: Thu Sep 24 14:52:24 2020
Subject: [odb-users] 'unordered_set' is not a member of 'std'
In-Reply-To: <boris.20200917134848@codesynthesis.com>
References: <CALWbUmkYBB3kpgWSCnYmRcru2bAksv7zo6NKEE8SLRPUuRB7Hg@mail.gmail.com>
	<boris.20200917134848@codesynthesis.com>
Message-ID: <CALWbUm=wcFX9wdx+16W9e_6uFbDfLVG-QsuS0GHZ20QpABmnTQ@mail.gmail.com>

Thank you, Boris, I will give 2.5.0 pre-release a try.  Just curious if the
older method of distribution (gzipped tar files) will be a possibility for
2.5?

Thanks again,
Craig


On Thu, Sep 17, 2020 at 4:55 AM Boris Kolpackov <boris@codesynthesis.com>
wrote:

> Craig Burton <rccraigb@gmail.com> writes:
>
> > /usr/local/odb-2.4.0/bin/odb --std c++14  --database mysql
> > --generate-schema --generate-query --profile boost/date-time
> > --generate-session --default-pointer std::tr1::shared_ptr
>
> My guess would be there is some interference from Boost TR1 (that
> whole TR1 support injection is quite hacky). Seeing that you are
> using C++14, I would suggest using --default-pointer std::shared_ptr.
> I would also suggest upgrading[1] to the latest 2.5.0 pre-release
> since we've cleaned up some of that TR1 stuff since 2.4.0.
>
> [1] https://codesynthesis.com/products/odb/doc/install-build2.xhtml
>
From boris at codesynthesis.com  Fri Sep 25 10:08:55 2020
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Sep 25 10:27:02 2020
Subject: [odb-users] 'unordered_set' is not a member of 'std'
In-Reply-To: <CALWbUm=wcFX9wdx+16W9e_6uFbDfLVG-QsuS0GHZ20QpABmnTQ@mail.gmail.com>
References: <CALWbUmkYBB3kpgWSCnYmRcru2bAksv7zo6NKEE8SLRPUuRB7Hg@mail.gmail.com>
	<boris.20200917134848@codesynthesis.com>
	<CALWbUm=wcFX9wdx+16W9e_6uFbDfLVG-QsuS0GHZ20QpABmnTQ@mail.gmail.com>
Message-ID: <boris.20200925160109@codesynthesis.com>

Craig Burton <rccraigb@gmail.com> writes:

> Just curious if the older method of distribution (gzipped tar files) will
> be a possibility for 2.5?

If you mean with pre-built binaries of the ODB compiler (and bundled
GCC), then the answer is no. This proved to be very fragile with GCC
often breaking in obscure ways due to changes in system headers.

We do plan to provide (as a general build2 mechanism) automatic
creation of distribution packages (.deb, .rpm, etc., could probably
also be plain .tar.gz) but those won't include bundled GCC (so the
result will only work on the same distribution/version). You can
already do this manually as shown here:

https://www.codesynthesis.com/pipermail/odb-users/2020-July/004540.html

From rccraigb at gmail.com  Fri Sep 25 13:13:08 2020
From: rccraigb at gmail.com (Craig Burton)
Date: Fri Sep 25 13:31:34 2020
Subject: [odb-users] 'unordered_set' is not a member of 'std'
In-Reply-To: <boris.20200925160109@codesynthesis.com>
References: <CALWbUmkYBB3kpgWSCnYmRcru2bAksv7zo6NKEE8SLRPUuRB7Hg@mail.gmail.com>
	<boris.20200917134848@codesynthesis.com>
	<CALWbUm=wcFX9wdx+16W9e_6uFbDfLVG-QsuS0GHZ20QpABmnTQ@mail.gmail.com>
	<boris.20200925160109@codesynthesis.com>
Message-ID: <CALWbUm=UVrspC2qOwUogTvO54tkz3Ao5BS_6h3-kpMAQ8MM1+A@mail.gmail.com>

The manual creation of packages looks like a very workable solution --
thank you!

On Fri, Sep 25, 2020 at 7:09 AM Boris Kolpackov <boris@codesynthesis.com>
wrote:

> Craig Burton <rccraigb@gmail.com> writes:
>
> > Just curious if the older method of distribution (gzipped tar files) will
> > be a possibility for 2.5?
>
> If you mean with pre-built binaries of the ODB compiler (and bundled
> GCC), then the answer is no. This proved to be very fragile with GCC
> often breaking in obscure ways due to changes in system headers.
>
> We do plan to provide (as a general build2 mechanism) automatic
> creation of distribution packages (.deb, .rpm, etc., could probably
> also be plain .tar.gz) but those won't include bundled GCC (so the
> result will only work on the same distribution/version). You can
> already do this manually as shown here:
>
> https://www.codesynthesis.com/pipermail/odb-users/2020-July/004540.html
>
From rccraigb at gmail.com  Fri Sep 25 16:44:05 2020
From: rccraigb at gmail.com (Craig Burton)
Date: Fri Sep 25 17:02:32 2020
Subject: [odb-users] ODB 2.5.0-b.19 self-referential attribute mapping error
Message-ID: <CALWbUmmcuXc=xtP7MnD93oXp3DNZ=KjUH3AiW3g68DTidWUdSg@mail.gmail.com>

Hi,

In updating from 2.4 to 2.5, I'm hitting an issue for a class that
represents nodes in a graph, resulting in this error:

Node.h:14:28: error: unable to map C++ type '::boost::shared_ptr< ::Node >'
used in data member '_above' to a MySQL database type
Node.h:14:28: info: use '#pragma db type' to specify the database type

This worked in 2.4; I'm wondering if I've not properly set up my 2.5
environment.  This is the class definition:

#include <odb/core.hxx>
#include <boost/shared_ptr.hpp>
#include <boost/weak_ptr.hpp>

#pragma db object table ("Node")
class Node
{
protected:
   friend class odb::access;
   #pragma db id auto
   unsigned long id_;

private:
   boost::shared_ptr<Node> _above;

   #pragma db value_not_null inverse(_above)
   std::vector<boost::weak_ptr<Node> > _below;
};

This is the command used to invoke the odb compiler:
/usr/local/odb-2.5.0/bin/odb \
--database mysql \
--std c++11 \
--generate-schema \
--generate-query \
--profile boost/date-time \
--generate-session \
--at-once \
--input-name Depot \
-I/home/cburton/Development/odb-2.5-runtime/odb/include \
-I/usr/local/boost_1_62_0 Node.h

odb compiler output with -v listed below.

Thank you in advance!
Craig

Profile search paths:
 /home/cburton/Development/odb-2.5-runtime/odb/include
 /usr/local/boost_1_62_0
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
Compiling Node.h
g++ -x c++ -std=c++0x -S -Wunknown-pragmas -Wno-deprecated
-fplugin=/usr/local/odb-2.5.0/bin/odb.so -v
-I/home/cburton/Development/odb-2.5-runtime/odb/include
-I/usr/local/boost_1_62_0
-fplugin-arg-odb-svc-path=/home/cburton/Development/odb-2.5-runtime/odb/include
-fplugin-arg-odb-svc-path=/usr/local/boost_1_62_0
-fplugin-arg-odb-svc-path=/usr/include/c++/5
-fplugin-arg-odb-svc-path=/usr/include/x86_64-linux-gnu/c++/5
-fplugin-arg-odb-svc-path=/usr/include/c++/5/backward
-fplugin-arg-odb-svc-path=/usr/lib/gcc/x86_64-linux-gnu/5/include
-fplugin-arg-odb-svc-path=/usr/local/include
-fplugin-arg-odb-svc-path=/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
-fplugin-arg-odb-svc-path=/usr/include/x86_64-linux-gnu
-fplugin-arg-odb-svc-path=/usr/include -DODB_COMPILER
-DODB_COMPILER_VERSION=2049969 -DODB_DATABASE_MYSQL
-fplugin-arg-odb-database=mysql -fplugin-arg-odb-std=c++11
-fplugin-arg-odb-generate-schema -fplugin-arg-odb-generate-query
-fplugin-arg-odb-profile=boost/date-time -fplugin-arg-odb-generate-session
-fplugin-arg-odb-at-once -fplugin-arg-odb-input-name=Depot
-fplugin-arg-odb-svc-file=Node.h -
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.12'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)
COLLECT_GCC_OPTIONS='-std=c++11' '-S' '-Wunknown-pragmas' '-Wno-deprecated'
'-fplugin=/usr/local/odb-2.5.0/bin/odb.so' '-v' '-I'
'/home/cburton/Development/odb-2.5-runtime/odb/include' '-I'
'/usr/local/boost_1_62_0'
'-fplugin-arg-odb-svc-path=/home/cburton/Development/odb-2.5-runtime/odb/include'
'-fplugin-arg-odb-svc-path=/usr/local/boost_1_62_0'
'-fplugin-arg-odb-svc-path=/usr/include/c++/5'
'-fplugin-arg-odb-svc-path=/usr/include/x86_64-linux-gnu/c++/5'
'-fplugin-arg-odb-svc-path=/usr/include/c++/5/backward'
'-fplugin-arg-odb-svc-path=/usr/lib/gcc/x86_64-linux-gnu/5/include'
'-fplugin-arg-odb-svc-path=/usr/local/include'
'-fplugin-arg-odb-svc-path=/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed'
'-fplugin-arg-odb-svc-path=/usr/include/x86_64-linux-gnu'
'-fplugin-arg-odb-svc-path=/usr/include' '-D' 'ODB_COMPILER' '-D'
'ODB_COMPILER_VERSION=2049969' '-D' 'ODB_DATABASE_MYSQL'
'-fplugin-arg-odb-database=mysql' '-fplugin-arg-odb-std=c++11'
'-fplugin-arg-odb-generate-schema' '-fplugin-arg-odb-generate-query'
'-fplugin-arg-odb-profile=boost/date-time'
'-fplugin-arg-odb-generate-session' '-fplugin-arg-odb-at-once'
'-fplugin-arg-odb-input-name=Depot' '-fplugin-arg-odb-svc-file=Node.h'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -quiet -v -I
/home/cburton/Development/odb-2.5-runtime/odb/include -I
/usr/local/boost_1_62_0 -imultiarch x86_64-linux-gnu
-iplugindir=/usr/lib/gcc/x86_64-linux-gnu/5/plugin -D_GNU_SOURCE -D
ODB_COMPILER -D ODB_COMPILER_VERSION=2049969 -D ODB_DATABASE_MYSQL -
-iplugindir=/usr/lib/gcc/x86_64-linux-gnu/5/plugin -quiet -dumpbase -
-mtune=generic -march=x86-64 -auxbase - -Wunknown-pragmas -Wno-deprecated
-std=c++11 -version -fplugin=/usr/local/odb-2.5.0/bin/odb.so
-fplugin-arg-odb-svc-path=/home/cburton/Development/odb-2.5-runtime/odb/include
-fplugin-arg-odb-svc-path=/usr/local/boost_1_62_0
-fplugin-arg-odb-svc-path=/usr/include/c++/5
-fplugin-arg-odb-svc-path=/usr/include/x86_64-linux-gnu/c++/5
-fplugin-arg-odb-svc-path=/usr/include/c++/5/backward
-fplugin-arg-odb-svc-path=/usr/lib/gcc/x86_64-linux-gnu/5/include
-fplugin-arg-odb-svc-path=/usr/local/include
-fplugin-arg-odb-svc-path=/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
-fplugin-arg-odb-svc-path=/usr/include/x86_64-linux-gnu
-fplugin-arg-odb-svc-path=/usr/include -fplugin-arg-odb-database=mysql
-fplugin-arg-odb-std=c++11 -fplugin-arg-odb-generate-schema
-fplugin-arg-odb-generate-query -fplugin-arg-odb-profile=boost/date-time
-fplugin-arg-odb-generate-session -fplugin-arg-odb-at-once
-fplugin-arg-odb-input-name=Depot -fplugin-arg-odb-svc-file=Node.h -o -.s
-fstack-protector-strong -Wformat -Wformat-security
GNU C++11 (Ubuntu 5.4.0-6ubuntu1~16.04.12) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR version
3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Versions of loaded plugins:
 odb: 2.5.0-b.19
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/cburton/Development/odb-2.5-runtime/odb/include
 /usr/local/boost_1_62_0
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++11 (Ubuntu 5.4.0-6ubuntu1~16.04.12) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR version
3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Versions of loaded plugins:
 odb: 2.5.0-b.19
Compiler executable checksum: 85af4995304287cdd19cfa43cf5d6cf1
Node.h:14:28: error: unable to map C++ type '::boost::shared_ptr< ::Node >'
used in data member '_above' to a MySQL database type
Node.h:14:28: info: use '#pragma db type' to specify the database type
From boris at codesynthesis.com  Mon Sep 28 07:43:14 2020
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Sep 28 08:01:31 2020
Subject: [odb-users] ODB 2.5.0-b.19 self-referential attribute mapping
	error
In-Reply-To: <CALWbUmmcuXc=xtP7MnD93oXp3DNZ=KjUH3AiW3g68DTidWUdSg@mail.gmail.com>
References: <CALWbUmmcuXc=xtP7MnD93oXp3DNZ=KjUH3AiW3g68DTidWUdSg@mail.gmail.com>
Message-ID: <boris.20200928134122@codesynthesis.com>

Craig Burton <rccraigb@gmail.com> writes:

> #include <odb/core.hxx>
> #include <boost/shared_ptr.hpp>
> #include <boost/weak_ptr.hpp>
> 
> #pragma db object table ("Node")
> class Node
> {
> protected:
>    friend class odb::access;
>    #pragma db id auto
>    unsigned long id_;
> 
> private:
>    boost::shared_ptr<Node> _above;
> 
>    #pragma db value_not_null inverse(_above)
>    std::vector<boost::weak_ptr<Node> > _below;
> };
> 
> /usr/local/odb-2.5.0/bin/odb \
> --database mysql \
> --std c++11 \
> --generate-schema \
> --generate-query \
> --profile boost/date-time \
> --generate-session \
> --at-once \
> --input-name Depot \
> -I/home/cburton/Development/odb-2.5-runtime/odb/include \
> -I/usr/local/boost_1_62_0 Node.h

I am pretty sure you need to enable the boot/smart-ptr profile (which
includes traits for boost::*_ptr and makes boost::shared_ptr the default
object pointer).

From odb at a-cunningham.com  Mon Sep 28 12:59:27 2020
From: odb at a-cunningham.com (Andrew Cunningham)
Date: Mon Sep 28 13:18:06 2020
Subject: [odb-users] Data migration question
Message-ID: <CAGTJuHhkZ+KJFHmw7RhZT87pfxP+d9YNooY8oAmbgVL7DwjXeg@mail.gmail.com>

The documentation is not 100% clear on one point about data migration.

As per the example, this function migrates some object types in the
database from any version in the range [MYAPP_BASE_VERSION,2] to version 3

static const odb::data_migration_entry<3, MYAPP_BASE_VERSION>
migrate_gender_entry (&migrate_gender);

What is not 100% clear is what happens when the current database version is
>3 ( say 4). Will this function still be called to migrate the objects or
do I need to update it to

static const odb::data_migration_entry<4, MYAPP_BASE_VERSION>
migrate_gender_entry (&migrate_gender);
From rccraigb at gmail.com  Mon Sep 28 14:17:46 2020
From: rccraigb at gmail.com (Craig Burton)
Date: Mon Sep 28 14:36:22 2020
Subject: [odb-users] ODB 2.5.0-b.19 self-referential attribute mapping
	error
In-Reply-To: <boris.20200928134122@codesynthesis.com>
References: <CALWbUmmcuXc=xtP7MnD93oXp3DNZ=KjUH3AiW3g68DTidWUdSg@mail.gmail.com>
	<boris.20200928134122@codesynthesis.com>
Message-ID: <CALWbUmmvm2SBPyvn57msip3tZ0f-wzwogQBNAmQmNH+oa6A4mw@mail.gmail.com>

Thank you, that was it!

Much appreciated,
Craig

On Mon, Sep 28, 2020 at 4:43 AM Boris Kolpackov <boris@codesynthesis.com>
wrote:

> Craig Burton <rccraigb@gmail.com> writes:
>
> > #include <odb/core.hxx>
> > #include <boost/shared_ptr.hpp>
> > #include <boost/weak_ptr.hpp>
> >
> > #pragma db object table ("Node")
> > class Node
> > {
> > protected:
> >    friend class odb::access;
> >    #pragma db id auto
> >    unsigned long id_;
> >
> > private:
> >    boost::shared_ptr<Node> _above;
> >
> >    #pragma db value_not_null inverse(_above)
> >    std::vector<boost::weak_ptr<Node> > _below;
> > };
> >
> > /usr/local/odb-2.5.0/bin/odb \
> > --database mysql \
> > --std c++11 \
> > --generate-schema \
> > --generate-query \
> > --profile boost/date-time \
> > --generate-session \
> > --at-once \
> > --input-name Depot \
> > -I/home/cburton/Development/odb-2.5-runtime/odb/include \
> > -I/usr/local/boost_1_62_0 Node.h
>
> I am pretty sure you need to enable the boot/smart-ptr profile (which
> includes traits for boost::*_ptr and makes boost::shared_ptr the default
> object pointer).
>
From boris at codesynthesis.com  Tue Sep 29 10:06:56 2020
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Sep 29 10:25:17 2020
Subject: [odb-users] Data migration question
In-Reply-To: <CAGTJuHhkZ+KJFHmw7RhZT87pfxP+d9YNooY8oAmbgVL7DwjXeg@mail.gmail.com>
References: <CAGTJuHhkZ+KJFHmw7RhZT87pfxP+d9YNooY8oAmbgVL7DwjXeg@mail.gmail.com>
Message-ID: <boris.20200929155708@codesynthesis.com>

Andrew Cunningham <odb@a-cunningham.com> writes:

> The documentation is not 100% clear on one point about data migration.
> 
> As per the example, this function migrates some object types in the
> database from any version in the range [MYAPP_BASE_VERSION,2] to version 3
> 
> static const odb::data_migration_entry<3, MYAPP_BASE_VERSION>
> migrate_gender_entry (&migrate_gender);

Not exactly: this function is called if and when migrating from version
2 to version 3. The second template argument is there to detect when this
entry is no longer necessary. Quoting the manual:

"The first template argument to the data_migration_entry class template is the
 version we want this data migration function to be called for. The second
 template argument is the base model version. This second argument is
 necessary to detect the situation where we no longer need this data migration
 function. Remember that when we move the base model version forward,
 migrations from any version below the new base are no longer possible. We,
 however, may still have migration functions registered for those lower
 versions. Since these functions will never be called, they are effectively
 dead code and it would be useful to identify and remove them. [...]"


> What is not 100% clear is what happens when the current database version is
> >3 ( say 4). Will this function still be called to migrate the objects or
> do I need to update it to
> 
> static const odb::data_migration_entry<4, MYAPP_BASE_VERSION>
> migrate_gender_entry (&migrate_gender);

Normally not. This entry is a migration "step" when migrating from version
2 to version 3. If the database is currently at version 2, then it will
be called for the 2->3 step (which will then be followed by 3->4). If,
however, the database is already at version 3 then presumably the data
is already in the desired state (from this step's point of view).

From odb at a-cunningham.com  Tue Sep 29 11:42:06 2020
From: odb at a-cunningham.com (Andrew Cunningham)
Date: Tue Sep 29 12:00:49 2020
Subject: [odb-users] Data migration question
In-Reply-To: <boris.20200929155708@codesynthesis.com>
References: <CAGTJuHhkZ+KJFHmw7RhZT87pfxP+d9YNooY8oAmbgVL7DwjXeg@mail.gmail.com>
	<boris.20200929155708@codesynthesis.com>
Message-ID: <CAGTJuHh2QrpzMdUMNK7QHQ4z=dRv0S84MNUuPoCXZk_gxt5Q6w@mail.gmail.com>

Thanks, you  are confirming what I expect to happen.
If the database being migrated is at version 2, and the current database
version is at version 3 *or greater*, then 2->3 migration entries will be
called.

On Tue, Sep 29, 2020 at 7:07 AM Boris Kolpackov <boris@codesynthesis.com>
wrote:

> Andrew Cunningham <odb@a-cunningham.com> writes:
>
> > The documentation is not 100% clear on one point about data migration.
> >
> > As per the example, this function migrates some object types in the
> > database from any version in the range [MYAPP_BASE_VERSION,2] to version
> 3
> >
> > static const odb::data_migration_entry<3, MYAPP_BASE_VERSION>
> > migrate_gender_entry (&migrate_gender);
>
> Not exactly: this function is called if and when migrating from version
> 2 to version 3. The second template argument is there to detect when this
> entry is no longer necessary. Quoting the manual:
>
> "The first template argument to the data_migration_entry class template is
> the
>  version we want this data migration function to be called for. The second
>  template argument is the base model version. This second argument is
>  necessary to detect the situation where we no longer need this data
> migration
>  function. Remember that when we move the base model version forward,
>  migrations from any version below the new base are no longer possible. We,
>  however, may still have migration functions registered for those lower
>  versions. Since these functions will never be called, they are effectively
>  dead code and it would be useful to identify and remove them. [...]"
>
>
> > What is not 100% clear is what happens when the current database version
> is
> > >3 ( say 4). Will this function still be called to migrate the objects or
> > do I need to update it to
> >
> > static const odb::data_migration_entry<4, MYAPP_BASE_VERSION>
> > migrate_gender_entry (&migrate_gender);
>
> Normally not. This entry is a migration "step" when migrating from version
> 2 to version 3. If the database is currently at version 2, then it will
> be called for the 2->3 step (which will then be followed by 3->4). If,
> however, the database is already at version 3 then presumably the data
> is already in the desired state (from this step's point of view).
>