From davejohansen at gmail.com  Tue Jan  8 22:57:20 2013
From: davejohansen at gmail.com (Dave Johansen)
Date: Tue Jan  8 22:43:46 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
Message-ID: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>

Does anyone know if it's possible to enable or install plugin support on
RHEL/CentOS 5 and 6? I would like to build and install odb on RHEL/CentOS 5
and 6, but I haven't been able to figure out how to get plugin support
working with gcc.
Thanks,
Dave
From boris at codesynthesis.com  Wed Jan  9 09:02:15 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jan  9 08:11:36 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
In-Reply-To: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
References: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
Message-ID: <boris.20130109154702@codesynthesis.com>

Hi Dave,

Dave Johansen <davejohansen@gmail.com> writes:

> Does anyone know if it's possible to enable or install plugin support on
> RHEL/CentOS 5 and 6? I would like to build and install odb on RHEL/CentOS 5
> and 6, but I haven't been able to figure out how to get plugin support
> working with gcc.

Just to clarify a few things, only the ODB compiler requires plugin
support and can only be built with GCC 4.5.0 or later. On the other
hand, the ODB runtimes (i.e., libodb, libodb-<db>), examples, etc.,
can all be built with earlier versions of GCC.

I've done some research I it doesn't seem there is packaged GCC 4.5.0
or later for either RHEL/CentOS 5 or 6. They both seem to come with
GCC 4.4.X.

So your options are (from easier to more difficult):

1. Download the pre-built ODB compiler (the odb-X.Y.Z-<arch>-linux-gnu
   package). It includes a private copy of GCC with plugin support so all
   you have to do is download, unpack, and it is ready to go.

   In this setup you would use the stock GCC that comes with RHEL/CentOS
   to build the rest of the ODB (i.e., libodb, etc) as well as your
   application.

2. Build and install GCC 4.5.0 or later from source yourself. There
   are quite a few guides on the net that explain how to do this. To
   enable plugins you would add the --enable-plugin configure option.

   Once this is done you can then build the ODB compiler from source
   using this new GCC version.

Note also that once RHEL/CentOS 7 is out (presumably with GCC 4.5.0
or later), building ODB from source will become much easier. All you
will have to do is install the plugin support from the repository
(yum install gcc-plugin-devel). That's how it works on Fedora.

Boris

From davejohansen at gmail.com  Wed Jan  9 10:27:06 2013
From: davejohansen at gmail.com (Dave Johansen)
Date: Wed Jan  9 10:13:31 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
In-Reply-To: <boris.20130109154702@codesynthesis.com>
References: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
	<boris.20130109154702@codesynthesis.com>
Message-ID: <CAAcYxUcHwnLsxEzQfBoMOtgT5dpvmAjYXnMGEMd2oJ_0y7=m5Q@mail.gmail.com>

On Wed, Jan 9, 2013 at 7:02 AM, Boris Kolpackov <boris@codesynthesis.com>wrote:

> Hi Dave,
>
> Dave Johansen <davejohansen@gmail.com> writes:
>
> > Does anyone know if it's possible to enable or install plugin support on
> > RHEL/CentOS 5 and 6? I would like to build and install odb on
> RHEL/CentOS 5
> > and 6, but I haven't been able to figure out how to get plugin support
> > working with gcc.
>
> Just to clarify a few things, only the ODB compiler requires plugin
> support and can only be built with GCC 4.5.0 or later. On the other
> hand, the ODB runtimes (i.e., libodb, libodb-<db>), examples, etc.,
> can all be built with earlier versions of GCC.
>
> I've done some research I it doesn't seem there is packaged GCC 4.5.0
> or later for either RHEL/CentOS 5 or 6. They both seem to come with
> GCC 4.4.X.
>
> So your options are (from easier to more difficult):
>
> 1. Download the pre-built ODB compiler (the odb-X.Y.Z-<arch>-linux-gnu
>    package). It includes a private copy of GCC with plugin support so all
>    you have to do is download, unpack, and it is ready to go.
>
>    In this setup you would use the stock GCC that comes with RHEL/CentOS
>    to build the rest of the ODB (i.e., libodb, etc) as well as your
>    application.
>
> 2. Build and install GCC 4.5.0 or later from source yourself. There
>    are quite a few guides on the net that explain how to do this. To
>    enable plugins you would add the --enable-plugin configure option.
>
>    Once this is done you can then build the ODB compiler from source
>    using this new GCC version.
>
> Note also that once RHEL/CentOS 7 is out (presumably with GCC 4.5.0
> or later), building ODB from source will become much easier. All you
> will have to do is install the plugin support from the repository
> (yum install gcc-plugin-devel). That's how it works on Fedora.
>
> Boris
>

The platforms & compilers page says GCC 4.2-4.7, but I wasn't sure if that
was the compiler, the library, or both. I was afraid that that the compiler
might require a higher version of GCC than stated there, so maybe I'll give
option #1 a try and see if I can get it working.

However, I would like to get the standard packaging/rpm stuff setup and
maybe even contributed to the EPEL so it could be used easily by more than
just myself. I believe that's a lot easier of a process if it can be built
from source. But I'm assuming that the requirement for GCC 4.5 is because
of a feature that was introduced in that release (and I'm guessing it is
some enhanced C++0x support). Is that the case? And if so, how extensive is
the use of GCC 4.5 features? Basically, how hard would it be to get the odb
compiler to build on GCC 4.4?

Thanks,
Dave
From boris at codesynthesis.com  Wed Jan  9 14:22:40 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jan  9 13:31:56 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
In-Reply-To: <CAAcYxUcHwnLsxEzQfBoMOtgT5dpvmAjYXnMGEMd2oJ_0y7=m5Q@mail.gmail.com>
References: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
	<boris.20130109154702@codesynthesis.com>
	<CAAcYxUcHwnLsxEzQfBoMOtgT5dpvmAjYXnMGEMd2oJ_0y7=m5Q@mail.gmail.com>
Message-ID: <boris.20130109211244@codesynthesis.com>

Hi Dave,

Dave Johansen <davejohansen@gmail.com> writes:

> However, I would like to get the standard packaging/rpm stuff setup and
> maybe even contributed to the EPEL so it could be used easily by more than
> just myself.

That would definitely be great. If you were to do this you will have
"priority assistance" from me ;-).


> I believe that's a lot easier of a process if it can be built
> from source. 

Yes, the cleanest way to do it would be to use GCC that ships with RHEL
to build the ODB compiler from source.


> But I'm assuming that the requirement for GCC 4.5 is because of a
> feature that was introduced in that release (and I'm guessing it is
> some enhanced C++0x support). Is that the case?

Actually, it is the plugin support. The ODB compiler underneath is
implemented as a GCC plugin and uses the its frontend for C++ parsing.
And plugin support first appeared in GCC 4.5.0.


> And if so, how extensive is the use of GCC 4.5 features? Basically,
> how hard would it be to get the odb compiler to build on GCC 4.4?

I believe it would be pretty hard. Essentially we would need to
backport plugin support to GCC 4.4 and then convince RH to build
an update with this support.

I think, realistically, we can produce clean ODB packages for
RHEL 7 (and for Fedora). Maybe starting with Fedora is a good
idea.

For earlier versions the best bet is to package a private version
of GCC.

Boris

From davejohansen at gmail.com  Wed Jan  9 17:32:03 2013
From: davejohansen at gmail.com (Dave Johansen)
Date: Wed Jan  9 17:18:25 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
In-Reply-To: <boris.20130109211244@codesynthesis.com>
References: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
	<boris.20130109154702@codesynthesis.com>
	<CAAcYxUcHwnLsxEzQfBoMOtgT5dpvmAjYXnMGEMd2oJ_0y7=m5Q@mail.gmail.com>
	<boris.20130109211244@codesynthesis.com>
Message-ID: <CAAcYxUd8C__cAOsottdv6RhzWpUhvS_b8ZmKEmNxOb3bzMr0iQ@mail.gmail.com>

On Wed, Jan 9, 2013 at 12:22 PM, Boris Kolpackov <boris@codesynthesis.com>wrote:

> Hi Dave,
>
> Dave Johansen <davejohansen@gmail.com> writes:
>
> > However, I would like to get the standard packaging/rpm stuff setup and
> > maybe even contributed to the EPEL so it could be used easily by more
> than
> > just myself.
>
> That would definitely be great. If you were to do this you will have
> "priority assistance" from me ;-).
>
>
> > I believe that's a lot easier of a process if it can be built
> > from source.
>
> Yes, the cleanest way to do it would be to use GCC that ships with RHEL
> to build the ODB compiler from source.
>
>
> > But I'm assuming that the requirement for GCC 4.5 is because of a
> > feature that was introduced in that release (and I'm guessing it is
> > some enhanced C++0x support). Is that the case?
>
> Actually, it is the plugin support. The ODB compiler underneath is
> implemented as a GCC plugin and uses the its frontend for C++ parsing.
> And plugin support first appeared in GCC 4.5.0.
>
>
> > And if so, how extensive is the use of GCC 4.5 features? Basically,
> > how hard would it be to get the odb compiler to build on GCC 4.4?
>
> I believe it would be pretty hard. Essentially we would need to
> backport plugin support to GCC 4.4 and then convince RH to build
> an update with this support.
>
> I think, realistically, we can produce clean ODB packages for
> RHEL 7 (and for Fedora). Maybe starting with Fedora is a good
> idea.
>
> For earlier versions the best bet is to package a private version
> of GCC.
>
> Boris
>

I would definitely like to be able to get this setup, and would like to be
able to build it all on RHEL so it can be maintained as easily as possible
for an update and support perspective. I'm hoping to be able to use the
standard source RPM setup so it can all be easily built on a RHEL machine
without compiling things from a newer OS. But like you mentioned
previously, RHEL 5 and 6 only come with GCC 4.4, so what do you recommend
as the best way to do this? Have the source rpm also have GCC 4.5 that it
will build itself before building ODB and then packaging it with it like
your current binary builds do?

Thanks,
Dave
From davejohansen at gmail.com  Wed Jan  9 17:34:46 2013
From: davejohansen at gmail.com (Dave Johansen)
Date: Wed Jan  9 17:21:07 2013
Subject: [odb-users] Mention of version when plugin support was added?
Message-ID: <CAAcYxUe-0CjBbrJyha1jud45zhJR3F8JeYuWbGuD6To-aG5Hqw@mail.gmail.com>

This probably isn't the right place to post this, but the only place I
could find mention that plugin support was added to GCC in 4.5 was in the
4.5 release notes and that was because I knew to look there after seeing it
on this mailing list.

Does someone on here have access to the following sites to make a note of
that so other people looking into that like me can find that info easily:
http://gcc.gnu.org/wiki/plugins
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html

Thanks,
Dave
From boris at codesynthesis.com  Thu Jan 10 09:22:48 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Jan 10 08:31:54 2013
Subject: [odb-users] Mention of version when plugin support was added?
In-Reply-To: <CAAcYxUe-0CjBbrJyha1jud45zhJR3F8JeYuWbGuD6To-aG5Hqw@mail.gmail.com>
References: <CAAcYxUe-0CjBbrJyha1jud45zhJR3F8JeYuWbGuD6To-aG5Hqw@mail.gmail.com>
Message-ID: <boris.20130110162126@codesynthesis.com>

Hi Dave,

Dave Johansen <davejohansen@gmail.com> writes:

> http://gcc.gnu.org/wiki/plugins

I've added a note to this page.


> http://gcc.gnu.org/onlinedocs/gccint/Plugins.html

This is part of the GCC documentation so you will need to submit
a patch to the GCC mailing list if you want to add a note there.

Boris

From boris at codesynthesis.com  Thu Jan 10 09:58:44 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Jan 10 09:07:49 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
In-Reply-To: <CAAcYxUd8C__cAOsottdv6RhzWpUhvS_b8ZmKEmNxOb3bzMr0iQ@mail.gmail.com>
References: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
	<boris.20130109154702@codesynthesis.com>
	<CAAcYxUcHwnLsxEzQfBoMOtgT5dpvmAjYXnMGEMd2oJ_0y7=m5Q@mail.gmail.com>
	<boris.20130109211244@codesynthesis.com>
	<CAAcYxUd8C__cAOsottdv6RhzWpUhvS_b8ZmKEmNxOb3bzMr0iQ@mail.gmail.com>
Message-ID: <boris.20130110162553@codesynthesis.com>

Hi Dave,

Dave Johansen <davejohansen@gmail.com> writes:

> But like you mentioned previously, RHEL 5 and 6 only come with GCC 4.4,
> so what do you recommend as the best way to do this?

I think the best way to package ODB for RHEL 5 and 6 is to re-package
the binary package that we provide. Again, this will be a "legacy"
solution. For RHEL 7 and for Fedora that come with GCC 4.5 or later
we can implement the nice and clean "from source" approach.

I think using our binary package is better than trying to build and
package both GCC and ODB from source for the following reasons:

1. Building and especially packaging a private copy of GCC won't
   be trivial.

2. We already take great care to build a portable package that
   can work on a wide range of Linux distributions. Might as
   well re-use this hard work.

3. We are planning to keep releasing this binary package for the
   foreseeable future.

If you look inside, say, odb-X.Y.Z-x86_64-linux-gnu, you will see
that it already resembles a Linux filesystem pretty closely. That
is, the ODB compiler is in the bin/ sub-directory, configuration
is in etc/, and so on.

The only thing that doesn't quite fit is the x86_64-linux-gnu/
sub-directory which contains the private copy of GCC. Now, while
you can move doc/ and man/ sub-directories pretty much anywhere
you want, bin/, etc/, and x86_64-linux-gnu/ are expected to be
all at the same level: the ODB compiler uses the executable path
(i.e., .../bin/odb) to construct the paths to the default options
file (in etc/) and to the g++ executable (in x86_64-linux-gnu/).

The good news is that it is possible to override the path to g++
with the -x ODB compiler option. The bad news is that this option
is not recognized in the default options file, which is where we
could have conveniently put it if we were to move/rename
x86_64-linux-gnu to something more suitable.

So I went ahead and fixed this. If you would like to give it a try,
the binary for the 2.2.0.a2 pre-release is here:

http://codesynthesis.com/~boris/tmp/odb/odb-2.2.0.a2-x86_64-linux-gnu.tar.bz2

And the rest of the pre-release is here:

http://codesynthesis.com/download/odb/pre-release/

Specifically, with this binary, we can do the following:

1. Rename x86_64-linux-gnu/ to, say, lib/odb/gcc/, so that it is installed
   in /usr/lib/odb/gcc.

2. Add the following option to etc/odb/default.options:

   -x /usr/lib/odb/gcc/bin/g++

Other than that, the .spec file would just need to copy all the parts
into the right places, and that's it.

Now, that would only apply to packaging the ODB compiler. All the other
packages (libodb, libodb-<db>, etc) would be built and packaged from
source using the stock GCC that comes with RHEL.

Boris

From davejohansen at gmail.com  Thu Jan 10 10:24:05 2013
From: davejohansen at gmail.com (Dave Johansen)
Date: Thu Jan 10 10:10:21 2013
Subject: [odb-users] Mention of version when plugin support was added?
In-Reply-To: <boris.20130110162126@codesynthesis.com>
References: <CAAcYxUe-0CjBbrJyha1jud45zhJR3F8JeYuWbGuD6To-aG5Hqw@mail.gmail.com>
	<boris.20130110162126@codesynthesis.com>
Message-ID: <CAAcYxUdu=cN2D9rxBn3AH2QmixkAjQcnz-rbjOgkr2iP5o0DaQ@mail.gmail.com>

On Thu, Jan 10, 2013 at 7:22 AM, Boris Kolpackov <boris@codesynthesis.com>wrote:

> Hi Dave,
>
> Dave Johansen <davejohansen@gmail.com> writes:
>
> > http://gcc.gnu.org/wiki/plugins
>
> I've added a note to this page.
>
>
> > http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
>
> This is part of the GCC documentation so you will need to submit
> a patch to the GCC mailing list if you want to add a note there.
>
> Boris
>
>
Great! Thanks for updating the wiki and I'll look into submitting a patch
for the documentation.
Dave
From davejohansen at gmail.com  Fri Jan 11 10:27:29 2013
From: davejohansen at gmail.com (Dave Johansen)
Date: Fri Jan 11 10:13:37 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
In-Reply-To: <boris.20130110162553@codesynthesis.com>
References: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
	<boris.20130109154702@codesynthesis.com>
	<CAAcYxUcHwnLsxEzQfBoMOtgT5dpvmAjYXnMGEMd2oJ_0y7=m5Q@mail.gmail.com>
	<boris.20130109211244@codesynthesis.com>
	<CAAcYxUd8C__cAOsottdv6RhzWpUhvS_b8ZmKEmNxOb3bzMr0iQ@mail.gmail.com>
	<boris.20130110162553@codesynthesis.com>
Message-ID: <CAAcYxUfSx1bXsSgzC31arnJNxtJytMFWDP=8JwkVvpOKeCkPTA@mail.gmail.com>

On Thu, Jan 10, 2013 at 7:58 AM, Boris Kolpackov
<boris@codesynthesis.com> wrote:
> Hi Dave,
>
> Dave Johansen <davejohansen@gmail.com> writes:
>
>> But like you mentioned previously, RHEL 5 and 6 only come with GCC 4.4,
>> so what do you recommend as the best way to do this?
>
> I think the best way to package ODB for RHEL 5 and 6 is to re-package
> the binary package that we provide. Again, this will be a "legacy"
> solution. For RHEL 7 and for Fedora that come with GCC 4.5 or later
> we can implement the nice and clean "from source" approach.
>
> I think using our binary package is better than trying to build and
> package both GCC and ODB from source for the following reasons:
>
> 1. Building and especially packaging a private copy of GCC won't
>    be trivial.
>
> 2. We already take great care to build a portable package that
>    can work on a wide range of Linux distributions. Might as
>    well re-use this hard work.
>
> 3. We are planning to keep releasing this binary package for the
>    foreseeable future.
>
> If you look inside, say, odb-X.Y.Z-x86_64-linux-gnu, you will see
> that it already resembles a Linux filesystem pretty closely. That
> is, the ODB compiler is in the bin/ sub-directory, configuration
> is in etc/, and so on.
>
> The only thing that doesn't quite fit is the x86_64-linux-gnu/
> sub-directory which contains the private copy of GCC. Now, while
> you can move doc/ and man/ sub-directories pretty much anywhere
> you want, bin/, etc/, and x86_64-linux-gnu/ are expected to be
> all at the same level: the ODB compiler uses the executable path
> (i.e., .../bin/odb) to construct the paths to the default options
> file (in etc/) and to the g++ executable (in x86_64-linux-gnu/).
>
> The good news is that it is possible to override the path to g++
> with the -x ODB compiler option. The bad news is that this option
> is not recognized in the default options file, which is where we
> could have conveniently put it if we were to move/rename
> x86_64-linux-gnu to something more suitable.
>
> So I went ahead and fixed this. If you would like to give it a try,
> the binary for the 2.2.0.a2 pre-release is here:
>
> http://codesynthesis.com/~boris/tmp/odb/odb-2.2.0.a2-x86_64-linux-gnu.tar.bz2
>
> And the rest of the pre-release is here:
>
> http://codesynthesis.com/download/odb/pre-release/
>
> Specifically, with this binary, we can do the following:
>
> 1. Rename x86_64-linux-gnu/ to, say, lib/odb/gcc/, so that it is installed
>    in /usr/lib/odb/gcc.
>
> 2. Add the following option to etc/odb/default.options:
>
>    -x /usr/lib/odb/gcc/bin/g++
>
> Other than that, the .spec file would just need to copy all the parts
> into the right places, and that's it.
>
> Now, that would only apply to packaging the ODB compiler. All the other
> packages (libodb, libodb-<db>, etc) would be built and packaged from
> source using the stock GCC that comes with RHEL.
>
> Boris

You're right about building gcc as part of building the ODB compiler
being a pain, but I think it's the best option in the long run. It
means that everything that is needed is contained in the source RPM
and can be viewed and changed in one location and then the binary RPM
regenerated as needed. It makes audits/inspections of the code/RPM
easier and means that everything can be done in one place instead of
grabbing pieces from several places and bundling them up. Basically, I
think it's more work up front but makes everything a lot easier in the
long run. Is there somewhere that I can get access to how you built
and packaged gcc for your binary releases of the compiler?

Thanks,
Dave

From boris at codesynthesis.com  Fri Jan 11 11:32:41 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Jan 11 10:41:43 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
In-Reply-To: <CAAcYxUfSx1bXsSgzC31arnJNxtJytMFWDP=8JwkVvpOKeCkPTA@mail.gmail.com>
References: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
	<boris.20130109154702@codesynthesis.com>
	<CAAcYxUcHwnLsxEzQfBoMOtgT5dpvmAjYXnMGEMd2oJ_0y7=m5Q@mail.gmail.com>
	<boris.20130109211244@codesynthesis.com>
	<CAAcYxUd8C__cAOsottdv6RhzWpUhvS_b8ZmKEmNxOb3bzMr0iQ@mail.gmail.com>
	<boris.20130110162553@codesynthesis.com>
	<CAAcYxUfSx1bXsSgzC31arnJNxtJytMFWDP=8JwkVvpOKeCkPTA@mail.gmail.com>
Message-ID: <boris.20130111182456@codesynthesis.com>

Hi Dave,

Dave Johansen <davejohansen@gmail.com> writes:

> You're right about building gcc as part of building the ODB compiler
> being a pain, but I think it's the best option in the long run.

I think the long-term solution should be to migrate to RHEL 7 where
we can build and package everything using the stock GCC.

Another option would be to look if anyone packaged GCC 4.5 or later
(with plugin support enabled) for RHEL 5/6. Then we can just use that
package as a prerequisite instead of including a private copy of GCC.


> It means that everything that is needed is contained in the source RPM
> and can be viewed and changed in one location and then the binary RPM
> regenerated as needed. It makes audits/inspections of the code/RPM
> easier and means that everything can be done in one place instead of
> grabbing pieces from several places and bundling them up.

True, though you still need to get the source code for ODB. With
my approach you will just be getting a binary package instead of
the source one.


> Is there somewhere that I can get access to how you built and
> packaged gcc for your binary releases of the compiler?

Those scripts are not in the repository (yet), so I copied them for
your here:

http://www.codesynthesis.com/~boris/tmp/odb/linux-gnu.tar.bz2

Specifically, look into gcc-configure and build-gcc. Note also that
we build it on an old Debian distro (Sarge).

Boris

From davejohansen at gmail.com  Fri Jan 11 14:02:03 2013
From: davejohansen at gmail.com (Dave Johansen)
Date: Fri Jan 11 13:48:10 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
In-Reply-To: <boris.20130111182456@codesynthesis.com>
References: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
	<boris.20130109154702@codesynthesis.com>
	<CAAcYxUcHwnLsxEzQfBoMOtgT5dpvmAjYXnMGEMd2oJ_0y7=m5Q@mail.gmail.com>
	<boris.20130109211244@codesynthesis.com>
	<CAAcYxUd8C__cAOsottdv6RhzWpUhvS_b8ZmKEmNxOb3bzMr0iQ@mail.gmail.com>
	<boris.20130110162553@codesynthesis.com>
	<CAAcYxUfSx1bXsSgzC31arnJNxtJytMFWDP=8JwkVvpOKeCkPTA@mail.gmail.com>
	<boris.20130111182456@codesynthesis.com>
Message-ID: <CAAcYxUddBq1TGX0vKZks-hnbNP7LBZBbpTRWxN_K4BFshFf6-A@mail.gmail.com>

On Fri, Jan 11, 2013 at 9:32 AM, Boris Kolpackov <boris@codesynthesis.com>wrote:

> Hi Dave,
>
> Dave Johansen <davejohansen@gmail.com> writes:
>
> > You're right about building gcc as part of building the ODB compiler
> > being a pain, but I think it's the best option in the long run.
>
> I think the long-term solution should be to migrate to RHEL 7 where
> we can build and package everything using the stock GCC.
>

Yes, but we're just barely looking into moving to RHEL 6 and so it will be
a while until we'd consider moving to RHEL 7 and so I think that having a
long term solution that works on RHEL 5/6 is a good thing since both still
have quite a bit of life left in them.


> Another option would be to look if anyone packaged GCC 4.5 or later
> (with plugin support enabled) for RHEL 5/6. Then we can just use that
> package as a prerequisite instead of including a private copy of GCC.
>

RedHat is making GCC 4.7 available for RHEL 5/6, but it's not available as
part of the EPEL or any other standard source for CentOS:
http://www.redhat.com/summit/2012/pdf/2012-DevDay-How-To-Toolset-Newsome.pdf

Maybe it'd be worth trying to get that to be available in some sort of
standardize way and make it a dependency instead of bundling GCC with the
compiler.


> > It means that everything that is needed is contained in the source RPM
> > and can be viewed and changed in one location and then the binary RPM
> > regenerated as needed. It makes audits/inspections of the code/RPM
> > easier and means that everything can be done in one place instead of
> > grabbing pieces from several places and bundling them up.
>
> True, though you still need to get the source code for ODB. With
> my approach you will just be getting a binary package instead of
> the source one.
>

I just like the source way better because it means that everything is from
a known source. Some users get worried about distribution of binary blobs
and when it's build from source and they can build it themselves, then it
eases those concerns.


> > Is there somewhere that I can get access to how you built and
> > packaged gcc for your binary releases of the compiler?
>
> Those scripts are not in the repository (yet), so I copied them for
> your here:
>
> http://www.codesynthesis.com/~boris/tmp/odb/linux-gnu.tar.bz2
>
> Specifically, look into gcc-configure and build-gcc. Note also that
> we build it on an old Debian distro (Sarge).
>

Great! I'll check those out and see what I can get up and running.

Thanks for all of your help,
Dave
From chew.on.it at gmail.com  Sat Jan 12 11:25:03 2013
From: chew.on.it at gmail.com (Chew kk)
Date: Sun Jan 13 01:43:18 2013
Subject: [odb-users] MS SQL rowversion
Message-ID: <CAB=yNJMDNZz8qGhuBbCT7ztk+qkUhO5eQeic547s54UWUd-gug@mail.gmail.com>

Hi,

I'm currently evaluating Codesynthesis ODB and some potential issues just
cross my mind. Can the rowversion type in MSSQL mapped to C++ type? How
should I mapped? While MSSQL is using rowversion for optimistic currency,
can rowversion type be used as object version in ODB? I've an existing
application using rowversion of MSSQL for optimistic concurrency.
Specifically, it is using LINQ for database access. Another upcoming
application also needs to access same database but it needs to use ODB for
database access. In order not to break any existing applications, I can't
change the schema of the database. By the way, will there be any problems
for LINQ and ODB to collaborate?

Regards,
chew
From boris at codesynthesis.com  Sun Jan 13 05:04:30 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Jan 13 04:13:00 2013
Subject: [odb-users] MS SQL rowversion
In-Reply-To: <CAB=yNJMDNZz8qGhuBbCT7ztk+qkUhO5eQeic547s54UWUd-gug@mail.gmail.com>
References: <CAB=yNJMDNZz8qGhuBbCT7ztk+qkUhO5eQeic547s54UWUd-gug@mail.gmail.com>
Message-ID: <boris.20130113115445@codesynthesis.com>

Hi Chew,

Chew kk <chew.on.it@gmail.com> writes:

> I'm currently evaluating Codesynthesis ODB and some potential issues just
> cross my mind. Can the rowversion type in MSSQL mapped to C++ type? How
> should I mapped? While MSSQL is using rowversion for optimistic currency,
> can rowversion type be used as object version in ODB?

ODB implements a portable approach to optimistic concurrency in which
it maintains a sequential version number for each row. This is quite
similar to MSSQL's ROWVERSION but there are a few differences, mainly
due to the SQL server doing the incrementing automatically (and not
necesssarily sequentially).

If you are seriously interested in using ODB, we can go ahead and
implement support for ROWVERSION for the next release (planned for
end-Jan). I will also be able to package you a pre-release to try
in a couple of days.


> By the way, will there be any problems for LINQ and ODB to collaborate?

I don't see any. They both interface with the data via the "MSSQL
interface", so to speak. If you can make them use the common schema
(and ODB is very flexible in this regard), then everything should
work fine.

Boris

From boris at codesynthesis.com  Sun Jan 13 05:38:16 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Jan 13 04:46:45 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
In-Reply-To: <CAAcYxUddBq1TGX0vKZks-hnbNP7LBZBbpTRWxN_K4BFshFf6-A@mail.gmail.com>
References: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
	<boris.20130109154702@codesynthesis.com>
	<CAAcYxUcHwnLsxEzQfBoMOtgT5dpvmAjYXnMGEMd2oJ_0y7=m5Q@mail.gmail.com>
	<boris.20130109211244@codesynthesis.com>
	<CAAcYxUd8C__cAOsottdv6RhzWpUhvS_b8ZmKEmNxOb3bzMr0iQ@mail.gmail.com>
	<boris.20130110162553@codesynthesis.com>
	<CAAcYxUfSx1bXsSgzC31arnJNxtJytMFWDP=8JwkVvpOKeCkPTA@mail.gmail.com>
	<boris.20130111182456@codesynthesis.com>
	<CAAcYxUddBq1TGX0vKZks-hnbNP7LBZBbpTRWxN_K4BFshFf6-A@mail.gmail.com>
Message-ID: <boris.20130113122059@codesynthesis.com>

Dave Johansen <davejohansen@gmail.com> writes:

> RedHat is making GCC 4.7 available for RHEL 5/6, but it's not available as
> part of the EPEL or any other standard source for CentOS:
> http://www.redhat.com/summit/2012/pdf/2012-DevDay-How-To-Toolset-Newsome.pdf

Thanks for sharing the link. I believe this is exactly what we need. It
will be much, much better than building and packaging our own GCC. The
end-users won't even have to use GCC 4.7 to build their application.
They can continue using GCC 4.1/4.4 and the ODB compiler will under
the hood use GCC 4.7 to do its work (so no need for that "enable ..."
calls mentioned on the slides). In other words, the way I see this
working from the user perspective:

1. Install GCC 4.7 .rpm from Developer Tools.

2. Install ODB compiler rpm (built with GCC 4.7).

3. Install ODB runtime .rpm's (built with GCC 4.1/4.4).

4. Build your application with GCC 4.1/4.4 without any concern for GCC 4.7
   (of course, if you want to use 4.7, nothing prevents you from doing so).

I did some Google'ing and there appears to be a CentOS build of Developer
Tools:

https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39506

Also, someone is working on the same for Scientific Linux:

http://www.mail-archive.com/scientific-linux-users@listserv.fnal.gov/msg12452.html

And, it appears that plugin support is enabled! I see for CentOS there is
this package:

devtoolset-1.0-gcc-plugin-devel-4.7.0-5.2.el5.centos.x86_64.rpm

Which I assume includes the plugin headers needed to build ODB (at least
that's what a package with the same name in Fedora contains). I think we
are all sorted.

Boris

From prokher at gmail.com  Mon Jan 14 07:24:16 2013
From: prokher at gmail.com (Alexander Prokhorov)
Date: Mon Jan 14 07:10:04 2013
Subject: [odb-users] Objects without primitive fields & NULL data to BLOB
Message-ID: <50F3F8F0.5030306@gmail.com>

Hi, Boris.

Thanks for your quick fix of polymorphic save/load of large objects in 
odb compiler. Now it works perfectly. However, we have encountered some 
fresh problems.

Some history - we use ODB with Qt profile and Sqlite, on multiple 
platforms. However, in-depth debugging was performed on linux-64 (ubuntu 
10, 11, 12).

1. [clear bug] It took some time to pinpoint exact problem, which is 
this - objects without any primitive fields can't be loaded. So, when 
persistent object contains only collections, load fails with syntax 
error - odb generates broken query like "SELECT FROM ...". Look into 
attached example odb_collections_test. Simple workaround is to add dummy 
primitive field to persistent class.

2. [bug or feature] Another strange thing that was encountered in same 
persistent classes - saving NULL data to "blob" type by custom traits. 
It's unclear, whether such operation is valid, however, I haven't found 
deep traits description that is deep enough to figure it out. It fails 
with 'object already persistent' message, which is, at least, 
perplexing. Message is clearly bad, the question is, can we save NULL 
blob at all? Non-null with zero size is ok. Look into attached example 
odb_traits_test.

Thanks in advance.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: odb_test.tar.gz
Type: application/x-gzip
Size: 3897 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/odb-users/attachments/20130114/5fba347c/odb_test.tar.bin
From boris at codesynthesis.com  Mon Jan 14 09:37:55 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Jan 14 08:46:06 2013
Subject: [odb-users] MS SQL rowversion
In-Reply-To: <CAB=yNJPj1Mh+eMH+nQYunJ9DGtqUFQF45ShntXzEKUGi8c6VUg@mail.gmail.com>
References: <CAB=yNJMDNZz8qGhuBbCT7ztk+qkUhO5eQeic547s54UWUd-gug@mail.gmail.com>
	<boris.20130113115445@codesynthesis.com>
	<CAB=yNJPj1Mh+eMH+nQYunJ9DGtqUFQF45ShntXzEKUGi8c6VUg@mail.gmail.com>
Message-ID: <boris.20130114161604@codesynthesis.com>

Hi Chew,

In the future please keep your replies CC'ed to the odb-users mailing
list as discussed in the posting guidelines:

http://www.codesynthesis.com/support/posting-guidelines.xhtml


Chew kk <chew.on.it@gmail.com> writes:

> Yes. I'm serious about adopting ODB as I do not have a better alternative,
> though I could go with QxOrm. However, QxOrm doesn't have a comprehensive
> user guide. It is great to hear that ODB is supporting rowversion.

It doesn't support it now but it will in the next release. In fact, I
just finished adding this support. If you would like to try it before
the final release (always a good idea), I can package you a pre-release.


> On the point of MSSQL not necessarily incrementing the rowversion
> sequentially, would that have any conflict on ODB's optimistic
> concurrency?

No, I've added a test and everything works fine.


> Just a clarification. With the rowversion added, I'll be able to do
> something like the following. Is that right?
> 
> #pragma db object optimistic
> class person
> {
> ...
> #pragma db version type("ROWVERSION")
> unsigned long version_;
> };

Yes, except that you will need to use unsigned long long (ROWVERSION
is a 64-bit value).


> I've another question concerning transaction. ODB didn't explicitly
> indicate the isolation level. Is it using read committed by default? Is
> there a way to set isolation level?

Yes, the default is the SQL Server default (READ COMMITTED). While there
is a way to set a custom isolation level now, it is not very convenient.
I will add an argument to the odb::mssql::database constructors that will
allow to specify an alternative value.

Boris

From boris at codesynthesis.com  Mon Jan 14 11:12:41 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Jan 14 10:20:54 2013
Subject: [odb-users] Objects without primitive fields & NULL data to BLOB
In-Reply-To: <50F3F8F0.5030306@gmail.com>
References: <50F3F8F0.5030306@gmail.com>
Message-ID: <boris.20130114180358@codesynthesis.com>

Hi Alexander,

Alexander Prokhorov <prokher@gmail.com> writes:

> 1. [clear bug] It took some time to pinpoint exact problem, which is  
> this - objects without any primitive fields can't be loaded. So, when  
> persistent object contains only collections, load fails with syntax  
> error - odb generates broken query like "SELECT FROM ...". Look into  
> attached example odb_collections_test. Simple workaround is to add dummy  
> primitive field to persistent class.

Fixed, thanks for the report and the test! Would you like a pre-release
with the fix (the fix affects the ODB compiler)?


> 2. [bug or feature] Another strange thing that was encountered in same  
> persistent classes - saving NULL data to "blob" type by custom traits.  
> It's unclear, whether such operation is valid, however, I haven't found  
> deep traits description that is deep enough to figure it out. It fails  
> with 'object already persistent' message, which is, at least,  
> perplexing. Message is clearly bad, the question is, can we save NULL  
> blob at all? Non-null with zero size is ok. Look into attached example  
> odb_traits_test.

Your data member in the persistent class does not allow NULL values.
To enable NULL, you will need to add the 'null' specifier to your
pragma, for example:

  #pragma db type("BLOB") null
  KludgyBool data;

You can also enable this on the per-type basis, if you wish:

#pragma db value(KludgyBool) type("BLOB") null

Newer versions of ODB also indicate whether the value can or cannot
be NULL via the is_null by-reference argument. That is, before calling
set_image(), ODB initializes this argument to true if the value can be
NULL and false otherwise.

As for why you get 'object already persistent' instead of, say 'NULL
constraint violation', see Section 14.5.4, "Constraint Violations"
in the ODB manual:

http://www.codesynthesis.com/products/odb/doc/manual.xhtml#14.5.4

Boris

From spiritonly at gmail.com  Mon Jan 14 22:52:15 2013
From: spiritonly at gmail.com (=?UTF-8?B?5p2o5rGf6aqF?=)
Date: Mon Jan 14 22:37:54 2013
Subject: [odb-users] oracle connection pool cause too many INACTIVE session
Message-ID: <CAEW4vWw+BJfu5e6XmRA4LNYhPPPNcoAY1k12OLtoLWucgy=O6g@mail.gmail.com>

Hi:
     I use following code to get database instance for singleton, but when
i close my exe, there are many INACTIVE sessions in oracle.
Then oracle's sessions will be exhausted. Someone can tell me how to close
all connections during close my exe.

static odb::database* get(const std::string& user, const std::string&
password, const std::string& dbName)
{
auto_ptr<odb::oracle::connection_factory> connection_pool(new
odb::oracle::connection_pool_factory (1, 10));
static odb::oracle::database _database(user, password, dbName, 0, 0, 0,
connection_pool);
return &_database;
}
From chew.on.it at gmail.com  Mon Jan 14 18:26:44 2013
From: chew.on.it at gmail.com (Chew kk)
Date: Tue Jan 15 04:37:04 2013
Subject: [odb-users] MS SQL rowversion
In-Reply-To: <boris.20130114161604@codesynthesis.com>
References: <CAB=yNJMDNZz8qGhuBbCT7ztk+qkUhO5eQeic547s54UWUd-gug@mail.gmail.com>
	<boris.20130113115445@codesynthesis.com>
	<CAB=yNJPj1Mh+eMH+nQYunJ9DGtqUFQF45ShntXzEKUGi8c6VUg@mail.gmail.com>
	<boris.20130114161604@codesynthesis.com>
Message-ID: <CAB=yNJMHEKjtENxAAxdWD+3ovO9Wy0DKEXpuyAoEk4xb0NYyQA@mail.gmail.com>

Hi Boris,

Noted. I'll CC'ed to odb-users mailing list. Can you send me the
pre-release binaries for windows x64?

Thanks,
Chew

On Mon, Jan 14, 2013 at 10:37 PM, Boris Kolpackov
<boris@codesynthesis.com>wrote:

> Hi Chew,
>
> In the future please keep your replies CC'ed to the odb-users mailing
> list as discussed in the posting guidelines:
>
> http://www.codesynthesis.com/support/posting-guidelines.xhtml
>
>
> Chew kk <chew.on.it@gmail.com> writes:
>
> > Yes. I'm serious about adopting ODB as I do not have a better
> alternative,
> > though I could go with QxOrm. However, QxOrm doesn't have a comprehensive
> > user guide. It is great to hear that ODB is supporting rowversion.
>
> It doesn't support it now but it will in the next release. In fact, I
> just finished adding this support. If you would like to try it before
> the final release (always a good idea), I can package you a pre-release.
>
>
> > On the point of MSSQL not necessarily incrementing the rowversion
> > sequentially, would that have any conflict on ODB's optimistic
> > concurrency?
>
> No, I've added a test and everything works fine.
>
>
> > Just a clarification. With the rowversion added, I'll be able to do
> > something like the following. Is that right?
> >
> > #pragma db object optimistic
> > class person
> > {
> > ...
> > #pragma db version type("ROWVERSION")
> > unsigned long version_;
> > };
>
> Yes, except that you will need to use unsigned long long (ROWVERSION
> is a 64-bit value).
>
>
> > I've another question concerning transaction. ODB didn't explicitly
> > indicate the isolation level. Is it using read committed by default? Is
> > there a way to set isolation level?
>
> Yes, the default is the SQL Server default (READ COMMITTED). While there
> is a way to set a custom isolation level now, it is not very convenient.
> I will add an argument to the odb::mssql::database constructors that will
> allow to specify an alternative value.
>
> Boris
>
From boris at codesynthesis.com  Tue Jan 15 07:48:13 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Jan 15 06:56:13 2013
Subject: [odb-users] oracle connection pool cause too many INACTIVE session
In-Reply-To: <CAEW4vWw+BJfu5e6XmRA4LNYhPPPNcoAY1k12OLtoLWucgy=O6g@mail.gmail.com>
References: <CAEW4vWw+BJfu5e6XmRA4LNYhPPPNcoAY1k12OLtoLWucgy=O6g@mail.gmail.com>
Message-ID: <boris.20130115143917@codesynthesis.com>

Hi,

spiritonly@gmail.com writes:

> I use following code to get database instance for singleton, but when
> i close my exe, there are many INACTIVE sessions in oracle.
>
> [...]
> 
> static odb::database* get(const std::string& user, const std::string&
>                           password, const std::string& dbName)
> {
>   auto_ptr<odb::oracle::connection_factory> connection_pool(new
>     odb::oracle::connection_pool_factory (1, 10));
>   static odb::oracle::database _database(user, password, dbName, 0, 0, 0,
>                                          connection_pool);
>   return &_database;
> }

The arguments you pass to the connection_pool_factory constructor are
invalid. max_connections (the first argument) should be greater or equal
to min_connections (the second argument).

Once this is fixed, the pooled connections will be automatically closed
when the database instance is destroyed, which in your case will happen
automatically if the application terminates normally (i.e., by returning
from main() or by calling exit()).

Boris

From boris at codesynthesis.com  Tue Jan 15 10:20:00 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Jan 15 09:27:58 2013
Subject: [odb-users] ODB 2.2.0.a3 available
Message-ID: <boris.20130115171246@codesynthesis.com>

Hi,

The third alpha version for the upcoming ODB 2.2.0 is now available. The
NEWS file entries so far are listed below. It also includes a large
number of other minor improvements and bug-fixes.

 * Multi-database support. It allows an application to simultaneously work
   with multiple database systems and comes in two flavors: static and
   dynamic. With static support the application uses the static database
   interfaces (that is, odb::<db>::database instead of odb::database). With
   dynamic support the same application code can access multiple databases
   via a common interface. Dynamic multi-database supports also allows the
   application to dynamically load the database support code for individual
   databases if and when necessary. For more information, refer to Chapter
   13, "Multi-Database Support" in the ODB manual.

 * Support for prepared queries. Prepared queries are a thin wrapper around
   the underlying database system's prepared statements functionality. They
   provide a way to perform potentially expensive query preparations tasks
   only once and then executing the query multiple time. For more information,
   refer to Section 4.5, "Prepared Queries" in the ODB manual as well as the
   'prepared' example in the odb-examples package.

 * Support for automatically-derived SQL name (table, column, index, etc.)
   transformations. At the higher level, it is possible to assign prefixes
   and suffixes (--table-prefix, --{index,fkey,sequence}--suffix options)
   as well as to convert to upper or lower case (--sql-name-case option).
   At the lower level, it is possible to specify transformations as regular
   expressions (--{table,column,index,fkey,sequence,sql-name}-regex options).
   For more information, refer to the SQL NAME TRANSFORMATIONS section in
   the ODB compiler command line interface documentation (man pages).

 * New options, --export-symbol and --extern-symbol, allow DLL exporting of
   the generated database support code.

 * Support for early connection release. Now the database connection is
   released when commit()/rollback() is called rather than when the
   transaction instance goes out of scope.

 * Support for SQL Server ROWVERSION-based optimistic concurrency. For more
   information, refer to Section 18.1.1, "ROWVERSION Support" in the ODB
   manual.

 * Support for specifying SQL Server transaction isolation level. For more
   information, refer to Section 18.2, "SQL Server Database Class" in the
   ODB manual.

This pre-release is available from:

http://www.codesynthesis.com/download/odb/pre-release/

The SHA1 sums for all the files in this pre-release are provided at the
end of the email.

Testing and feedback are much appreciated.

Enjoy,
	Boris

e136caae8205db5249966338161ef52f468b07db  libodb-2.2.0.a3.tar.bz2
cb3b6995ec6ba73e403bd44b2b5f0c2c8998b77d  libodb-2.2.0.a3.tar.gz
4d8548ada1f60d3f77b847966ed99831f69df561  libodb-2.2.0.a3.zip
1d8a5f77a76bc636e6603424aa3f8882068c924b  libodb-boost-2.2.0.a3.tar.bz2
aefc0bbf1dcc208bcc9ae949d6f0ff8378e1b636  libodb-boost-2.2.0.a3.tar.gz
a940d645a774eb5492ff6950b56a8b2947ad4bfb  libodb-boost-2.2.0.a3.zip
a7a7981e19f94fce22db4da8a559e20e86a8d6af  libodb-mssql-2.2.0.a3.tar.bz2
f3ac44230bd832194bd66703198e499c752f6418  libodb-mssql-2.2.0.a3.tar.gz
7402d0081bbf38f1f6945b9b7098a9e49f202269  libodb-mssql-2.2.0.a3.zip
bf0a6ff40aff5328d8d32faef4e46b1bbc6301e2  libodb-mysql-2.2.0.a3.tar.bz2
41ec4445c94dcd483c384eff4825760866a0f252  libodb-mysql-2.2.0.a3.tar.gz
161617672f38314c7448085e4d3df73dee4f55b4  libodb-mysql-2.2.0.a3.zip
6ee2290388feb6901509bde8e9e669c18696a6fc  libodb-oracle-2.2.0.a3.tar.bz2
b0f4a719d84e442748025f957a765ce1dff8f411  libodb-oracle-2.2.0.a3.tar.gz
35db639e616e4d7fa39f164dc96b5dcc155c9d3c  libodb-oracle-2.2.0.a3.zip
0b940b64e27af520e8ee1ab3d4c5e59acb71c367  libodb-pgsql-2.2.0.a3.tar.bz2
3e4ffcb0438af6f1ab1756d7454f3ad1a09f8345  libodb-pgsql-2.2.0.a3.tar.gz
192afa44fa18e8ee5df6bf6757fd6fead5b4f07e  libodb-pgsql-2.2.0.a3.zip
d7ae5e961487751dec6ff7f74ba40f52b1b54618  libodb-qt-2.2.0.a3.tar.bz2
8ef9187229305c481663e61fba4d9bdd060805b8  libodb-qt-2.2.0.a3.tar.gz
ff52a1d95d181197a90558ffde6e8b62636ededc  libodb-qt-2.2.0.a3.zip
e2b95e458292d9b54741730aa9ae11ffa4559f71  libodb-sqlite-2.2.0.a3.tar.bz2
7ad744f8b0996a43082d04050061e49fb5942332  libodb-sqlite-2.2.0.a3.tar.gz
f9396540defee17ffe0cd1f642f23b5ecf0ddc05  libodb-sqlite-2.2.0.a3.zip
f0ab2af1ef06031e2033f4333d4c30025847d14f  odb-2.2.0.a3-i686-linux-gnu.tar.bz2
a955dba1d11a1c3963f59702b66b8b60640e27fb  odb-2.2.0.a3-i686-windows.zip
23ccd1386fe84a89117a698da9607bb6596be4f5  odb-2.2.0.a3.tar.bz2
2faeb5ee17eedea99de1bb0f6938066235ddb884  odb-2.2.0.a3.tar.gz
3f382ae6ccc9a9726f60ca1d1b88bc9bd39a3932  odb-2.2.0.a3-x86_64-linux-gnu.tar.bz2
ac058c96f1fb3a1825d1cc884aac7898b7f3340c  odb-2.2.0.a3.zip
1120cdbb697596da7f406b82c9a4f2bd55854a4a  odb-examples-2.2.0.a3.tar.bz2
2937b3290ce21c56b10943d7a0c4b5043708d302  odb-examples-2.2.0.a3.tar.gz
b59e6f7907e375d10f297d82288009a8b81f6a7a  odb-examples-2.2.0.a3.zip
4fd0fc65aa953fbfb0f3c1287c0baa6d36b3015c  odb-tests-2.2.0.a3.tar.bz2
81cb73d821d1eb8b20dcc67df6d1578af44a3327  odb-tests-2.2.0.a3.tar.gz
d190220348b04937fc0a0b102c8b060fc0cc73a8  odb-tests-2.2.0.a3.zip

From tuxedo.catus at gmail.com  Tue Jan 15 13:04:56 2013
From: tuxedo.catus at gmail.com (Tuxedo F. Catus)
Date: Tue Jan 15 12:50:32 2013
Subject: [odb-users] Problem with 'char' field using ODB w/ SQLite
Message-ID: <CAFdMg-W3WqsOBAZoKARxU9BB3dN=+o1H4phfhrvV23x5EaZPjw@mail.gmail.com>

I am having a problem with a char field not coming out of the database
correctly, even though it appears fine when I query the database using
the sqlite3 binary.  Every other field is coming back correctly,
except for the 'EventType' field in the ShockParametersPrimaryKey
structure below.

This is my structure:

-- snip here --


#pragma db value
struct ShockParametersPrimaryKey {
    ShockParametersPrimaryKey() {}
#pragma db type( "VARCHAR(16)" )
    std::string m_Symbol;
    char m_EventType;
};

#pragma db object table( "ShockParameters" )
class ShockParametersDB {
    public:
        friend class odb::access;

#pragma db id
        ShockParametersPrimaryKey m_PrimaryKey;

        double m_AlphaShockScore;
        double m_BetaShockScore;
        double m_GammaShockScore;
        double m_DeltaShockScore;
        double m_EpsilonShockScore;
        double m_ZetaShockScore;
        double m_EtaShockScore;
        double m_ThetaShockScore;
};
-- snip here --


This is the schema generated:

-- snip here --
CREATE TABLE "ShockParameters" (
  "PrimaryKey_Symbol" VARCHAR(16) NOT NULL,
  "PrimaryKey_EventType" INTEGER NOT NULL,
  "AlphaShockScore" REAL NOT NULL,
  "BetaShockScore" REAL NOT NULL,
  "GammaShockScore" REAL NOT NULL,
  "DeltaShockScore" REAL NOT NULL,
  "EpsilonShockScore" REAL NOT NULL,
  "ZetaShockScore" REAL NOT NULL,
  "EtaShockScore" REAL NOT NULL,
  "ThetaShockScore" REAL NOT NULL,

  PRIMARY KEY (
    "PrimaryKey_Symbol",
    "PrimaryKey_EventType"));

--snip here--

Data is loaded into the database with a statement like this:

INSERT INTO "ShockParameters"
VALUES('SIRI','T',0.65,0.15,0.95,0.6,0.5,0.1,0.1,0.75);


Then the database is queried with the following code:

--snip--
          std::cout << "Shock Parameter Query: " << std::endl;
          ShockParametersDBResults shockqueryresult( paramdb->query<
ShockParametersDB >() );
          if( shockqueryresult.empty() ) {
              std::cout << "No shock parameter information available;
default fees will be returned." << std::endl;
          } else {
              std::for_each( shockqueryresult.begin(),
shockqueryresult.end(), [&]( ShockParametersDB& shock ) {
B =>              std::cout << "Shock Parameter Dump: " << std::endl;
<--- Notice debug breakpoint here
                  std::cout << shock << std::endl;
              });
          }
--snip--


But when I inspect the 'shock' value passed into the lamba at the
breakpoint ( B=> mark (emacs debug mode marker)), GDB shows me this --
notice the event type is not the 'T' that was loaded into the database
with the 'T' value:

$1 = (ShockParametersDB &) @0x634670: {

m_PrimaryKey = {m_Symbol = {static npos = <optimized out>, _M_dataplus
= {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No
data fields>}, <No data fields>}, _M_p = 0x6374f8 "SIRI"}\
},

m_EventType = 0 '\000'},

m_AlphaShockScore = 0.65000000000000002,
m_BetaShockScore = 0.14999999999999999,
m_GammaShockScore = 0.94999999999999996,
m_DeltaShockScore = 0.59999999999999998,
m_EpsilonShockScore = 0.5,
m_ZetaShockScore = 0.10000000000000001,
m_EtaShockScore = 0.10000000000000001,
m_ThetaShockScore = 0.75

}

My question is why is the character for m_EventType not coming back
properly, while everything else does come back correctly?

Thank you, in advance, for your assistance.

-T

From spiritonly at gmail.com  Tue Jan 15 19:49:42 2013
From: spiritonly at gmail.com (=?UTF-8?B?5p2o5rGf6aqF?=)
Date: Tue Jan 15 19:35:14 2013
Subject: [odb-users] oracle connection pool cause too many INACTIVE session
In-Reply-To: <boris.20130115143917@codesynthesis.com>
References: <CAEW4vWw+BJfu5e6XmRA4LNYhPPPNcoAY1k12OLtoLWucgy=O6g@mail.gmail.com>
	<boris.20130115143917@codesynthesis.com>
Message-ID: <CAEW4vWxTsQFCA40Wrn9pWfWNOMc1eF4AdxG0aZjz8ChOSJfmoA@mail.gmail.com>

Kolpackov:
     Thank you for answering. I'm careless about the order of the
parameters. I think the problem is solved.



On Tue, Jan 15, 2013 at 8:48 PM, Boris Kolpackov <boris@codesynthesis.com>wrote:

> Hi,
>
> spiritonly@gmail.com writes:
>
> > I use following code to get database instance for singleton, but when
> > i close my exe, there are many INACTIVE sessions in oracle.
> >
> > [...]
> >
> > static odb::database* get(const std::string& user, const std::string&
> >                           password, const std::string& dbName)
> > {
> >   auto_ptr<odb::oracle::connection_factory> connection_pool(new
> >     odb::oracle::connection_pool_factory (1, 10));
> >   static odb::oracle::database _database(user, password, dbName, 0, 0, 0,
> >                                          connection_pool);
> >   return &_database;
> > }
>
> The arguments you pass to the connection_pool_factory constructor are
> invalid. max_connections (the first argument) should be greater or equal
> to min_connections (the second argument).
>
> Once this is fixed, the pooled connections will be automatically closed
> when the database instance is destroyed, which in your case will happen
> automatically if the application terminates normally (i.e., by returning
> from main() or by calling exit()).
>
> Boris
>
From prokher at gmail.com  Wed Jan 16 04:03:26 2013
From: prokher at gmail.com (Alexander Prokhorov)
Date: Wed Jan 16 03:49:01 2013
Subject: [odb-users] Objects without primitive fields & NULL data to BLOB
In-Reply-To: <boris.20130114180358@codesynthesis.com>
References: <50F3F8F0.5030306@gmail.com>
	<boris.20130114180358@codesynthesis.com>
Message-ID: <50F66CDE.5080608@gmail.com>

Dear Boris,

thank you for quick response. My comments are in the text below.

On 01/14/2013 08:12 PM, Boris Kolpackov wrote:
> Hi Alexander,
>
> Alexander Prokhorov <prokher@gmail.com> writes:
>
>> 1. [clear bug] It took some time to pinpoint exact problem, which is
>> this - objects without any primitive fields can't be loaded. So, when
>> persistent object contains only collections, load fails with syntax
>> error - odb generates broken query like "SELECT FROM ...". Look into
>> attached example odb_collections_test. Simple workaround is to add dummy
>> primitive field to persistent class.
> Fixed, thanks for the report and the test! Would you like a pre-release
> with the fix (the fix affects the ODB compiler)?
That is great news. It would be great to have pre-release ODB compler 
for i686-windows, i686-linux-gnuo, x86_64-linux-gnu. Thank you in advance.
>
>
>> 2. [bug or feature] Another strange thing that was encountered in same
>> persistent classes - saving NULL data to "blob" type by custom traits.
>> It's unclear, whether such operation is valid, however, I haven't found
>> deep traits description that is deep enough to figure it out. It fails
>> with 'object already persistent' message, which is, at least,
>> perplexing. Message is clearly bad, the question is, can we save NULL
>> blob at all? Non-null with zero size is ok. Look into attached example
>> odb_traits_test.
> Your data member in the persistent class does not allow NULL values.
> To enable NULL, you will need to add the 'null' specifier to your
> pragma, for example:
>
>    #pragma db type("BLOB") null
>    KludgyBool data;
>
> You can also enable this on the per-type basis, if you wish:
>
> #pragma db value(KludgyBool) type("BLOB") null
>
> Newer versions of ODB also indicate whether the value can or cannot
> be NULL via the is_null by-reference argument. That is, before calling
> set_image(), ODB initializes this argument to true if the value can be
> NULL and false otherwise.
>
> As for why you get 'object already persistent' instead of, say 'NULL
> constraint violation', see Section 14.5.4, "Constraint Violations"
> in the ODB manual:
>
> http://www.codesynthesis.com/products/odb/doc/manual.xhtml#14.5.4
That is clear, thank you.
>
> Boris

From boris at codesynthesis.com  Wed Jan 16 06:52:31 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jan 16 06:00:15 2013
Subject: [odb-users] Objects without primitive fields & NULL data to BLOB
In-Reply-To: <50F66CDE.5080608@gmail.com>
References: <50F3F8F0.5030306@gmail.com>
	<boris.20130114180358@codesynthesis.com>
	<50F66CDE.5080608@gmail.com>
Message-ID: <boris.20130116135112@codesynthesis.com>

Hi Alexander,

Alexander Prokhorov <prokher@gmail.com> writes:

> That is great news. It would be great to have pre-release ODB compler  
> for i686-windows, i686-linux-gnuo, x86_64-linux-gnu.

We published 2.2.0.a3 yesterday, which includes this fix:

http://www.codesynthesis.com/pipermail/odb-announcements/2013/000024.html

Boris

From boris at codesynthesis.com  Wed Jan 16 07:13:44 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jan 16 06:21:30 2013
Subject: [odb-users] Problem with 'char' field using ODB w/ SQLite
In-Reply-To: <CAFdMg-W3WqsOBAZoKARxU9BB3dN=+o1H4phfhrvV23x5EaZPjw@mail.gmail.com>
References: <CAFdMg-W3WqsOBAZoKARxU9BB3dN=+o1H4phfhrvV23x5EaZPjw@mail.gmail.com>
Message-ID: <boris.20130116140250@codesynthesis.com>

Hi Tuxedo,

Tuxedo F. Catus <tuxedo.catus@gmail.com> writes:

> INSERT INTO "ShockParameters"
> VALUES('SIRI','T',0.65,0.15,0.95,0.6,0.5,0.1,0.1,0.75);
> 
> [...]
> 
> m_EventType = 0 '\000'},

I believe this is because of the SQLite dynamic type system. Even though
the database schema specifies that the EventType type is INTEGER, SQLite
will store pretty much anything in that column. And the above INSERT
statement inserts a string, not an integer. Here is simple illustration:

$ sqlite test.db
sqlite> CREATE TABLE foo (v INTEGER NOT NULL);
sqlite> INSERT INTO foo VALUES('T');
sqlite> INSERT INTO foo VALUES(123);
sqlite> SELECT v FROM foo;
T
123
sqlite> SELECT CAST(v AS INTEGER) FROM foo;
0
123

ODB extracts EventType as integer (equivalent to the second SELECT
statement), so what you get is 0.

An obvious way to fix this would be to specify an actual integer
value instead of a string in the INSERT statement.

Alternatively, if you want to continue using 'T' as the value, then
you would need to map the EventType column to TEXT. ODB does not yet
support mapping char (and char arrays; coming in the next release)
to TEXT so you will need to use std::string instead of char (or
implement your own mapping; which is also doable).

Boris

From prokher at gmail.com  Thu Jan 17 05:49:35 2013
From: prokher at gmail.com (Alexander Prokhorov)
Date: Thu Jan 17 05:35:01 2013
Subject: [odb-users] Objects without primitive fields & NULL data to BLOB
In-Reply-To: <boris.20130116135112@codesynthesis.com>
References: <50F3F8F0.5030306@gmail.com>
	<boris.20130114180358@codesynthesis.com>
	<50F66CDE.5080608@gmail.com>
	<boris.20130116135112@codesynthesis.com>
Message-ID: <50F7D73F.40608@gmail.com>

Thank you, I'll give a try.

On 01/16/2013 03:52 PM, Boris Kolpackov wrote:
> Hi Alexander,
>
> Alexander Prokhorov <prokher@gmail.com> writes:
>
>> That is great news. It would be great to have pre-release ODB compler
>> for i686-windows, i686-linux-gnuo, x86_64-linux-gnu.
> We published 2.2.0.a3 yesterday, which includes this fix:
>
> http://www.codesynthesis.com/pipermail/odb-announcements/2013/000024.html
>
> Boris

From danielpeterjames at gmail.com  Thu Jan 17 08:41:18 2013
From: danielpeterjames at gmail.com (Daniel James)
Date: Thu Jan 17 08:27:00 2013
Subject: [odb-users] sqlite, one to many relationship, std::map,
	std::weak_ptr
Message-ID: <CAAqNS9a=9giGcWqG-dF+hHSf9s0hrWCMn1N-Q06-0S-v1SCVfA@mail.gmail.com>

Hello

I hope my mistake here isn't too embarrassingly simple...

I have the following objects to persist:

class Child;
#pragma db object pointer(std::shared_ptr)
class Parent
{
public:

#pragma db inverse(parent)
  std::map<std::string, std::weak_ptr<Child>> children;
private:
  friend class odb::access;

#pragma db id auto
  unsigned long id_;
};

#pragma db object pointer(std::shared_ptr)
class Child
{
public:
  std::string name;
  std::shared_ptr<Parent> parent;
private:
  friend class odb::access;

#pragma db id auto
  unsigned long id_;
};

They are persisted to the following tables:

sqlite> select * from Child;
name        parent      id
----------  ----------  ----------
c1          1           1
c2          1           2
sqlite> select * from Parent;
id
----------
1
sqlite>

But upon retrieval of the Child objects I'm getting the following error:

SELECT "Parent"."id" FROM "Parent" WHERE "Parent"."id"=?
SELECT "Child"."id" FROM "Child" WHERE "Child"."parent"=?
Assertion failed: (static_cast<size_t> (sqlite3_data_count (stmt_)) == n),
function bind_result, file statement.cxx, line 152.
Abort trap: 6

Here's a program that demonstrates the issue:

int main(int argc, char *argv[])
{
  odb::sqlite::database db("test.db", SQLITE_OPEN_READWRITE |
SQLITE_OPEN_CREATE);
  {
    odb::connection_ptr c (db.connection ());
    c->execute ("PRAGMA foreign_keys=OFF");
    odb::transaction t (c->begin ());
    odb::schema_catalog::create_schema (db);
    t.commit ();
    c->execute ("PRAGMA foreign_keys=ON");
  }

  std::shared_ptr<Parent> p(std::make_shared<Parent>());
  std::shared_ptr<Child> c1(std::make_shared<Child>());
  c1->name = "c1";
  std::shared_ptr<Child> c2(std::make_shared<Child>());
  c2->name = "c2";

  p->children["c1"] = c1;
  p->children["c2"] = c2;
  c1->parent = p;
  c2->parent = p;
  try
    {
      odb::transaction t(db.begin());
      t.tracer(odb::stderr_tracer);

      db.persist(p);
      db.persist(c1);
      db.persist(c2);

      t.commit();
    }
  catch (odb::exception& e)
    {
      std::cerr << e.what() << '\n';
    }

  odb::transaction t2(db.begin());
  t2.tracer(odb::stderr_tracer);

  auto results(db.query(odb::query<Child>()));
  auto r(results.begin());

  std::cout << r->name << '\n';

  t2.commit();
  return 0;
}
From boris at codesynthesis.com  Thu Jan 17 10:20:17 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Jan 17 09:27:45 2013
Subject: [odb-users] sqlite, one to many relationship, std::map,
	std::weak_ptr
In-Reply-To: <CAAqNS9a=9giGcWqG-dF+hHSf9s0hrWCMn1N-Q06-0S-v1SCVfA@mail.gmail.com>
References: <CAAqNS9a=9giGcWqG-dF+hHSf9s0hrWCMn1N-Q06-0S-v1SCVfA@mail.gmail.com>
Message-ID: <boris.20130117171657@codesynthesis.com>

Hi Daniel,

Daniel James <danielpeterjames@gmail.com> writes:

>   #pragma db inverse(parent)
>   std::map<std::string, std::weak_ptr<Child>> children;

You cannot use a map container for an inverse side of a relationship.
While the ODB compiler does not yet diagnose this situation (I've
added a TODO item), the ODB manual mentions this in Section 12.4.14,
"inverse":

"An inverse member does not have a corresponding column or, in case
 of a container, table in the resulting database schema. Instead,
 the column or table from the referenced object is used to retrieve
 the relationship information. Only ordered and set containers can
 be used for inverse members. If an inverse member is of an ordered
 container type, it is automatically marked as unordered."

Boris

From danielpeterjames at gmail.com  Thu Jan 17 10:29:17 2013
From: danielpeterjames at gmail.com (Daniel James)
Date: Thu Jan 17 10:14:59 2013
Subject: [odb-users] sqlite, one to many relationship, std::map,
	std::weak_ptr
In-Reply-To: <boris.20130117171657@codesynthesis.com>
References: <CAAqNS9a=9giGcWqG-dF+hHSf9s0hrWCMn1N-Q06-0S-v1SCVfA@mail.gmail.com>
	<boris.20130117171657@codesynthesis.com>
Message-ID: <CAAqNS9ZKjmxsB23e-opGXkOcO2v3Xr7AV2b_dzNJNCRtmZZX+Q@mail.gmail.com>

On 17 January 2013 15:20, Boris Kolpackov <boris@codesynthesis.com> wrote:

> Hi Daniel,
>
> Daniel James <danielpeterjames@gmail.com> writes:
>
> >   #pragma db inverse(parent)
> >   std::map<std::string, std::weak_ptr<Child>> children;
>
> You cannot use a map container for an inverse side of a relationship.
> While the ODB compiler does not yet diagnose this situation (I've
> added a TODO item), the ODB manual mentions this in Section 12.4.14,
> "inverse":
>
> "An inverse member does not have a corresponding column or, in case
>  of a container, table in the resulting database schema. Instead,
>  the column or table from the referenced object is used to retrieve
>  the relationship information. Only ordered and set containers can
>  be used for inverse members. If an inverse member is of an ordered
>  container type, it is automatically marked as unordered."
>

Thanks for the answer. What's the rationale for not enabling std::map but
enabling std::set and 'ordered' containers?

Boris
>
From boris at codesynthesis.com  Thu Jan 17 12:41:28 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Jan 17 11:48:55 2013
Subject: [odb-users] sqlite, one to many relationship, std::map,
	std::weak_ptr
In-Reply-To: <CAAqNS9ZKjmxsB23e-opGXkOcO2v3Xr7AV2b_dzNJNCRtmZZX+Q@mail.gmail.com>
References: <CAAqNS9a=9giGcWqG-dF+hHSf9s0hrWCMn1N-Q06-0S-v1SCVfA@mail.gmail.com>
	<boris.20130117171657@codesynthesis.com>
	<CAAqNS9ZKjmxsB23e-opGXkOcO2v3Xr7AV2b_dzNJNCRtmZZX+Q@mail.gmail.com>
Message-ID: <boris.20130117193532@codesynthesis.com>

Hi Daniel,

Daniel James <danielpeterjames@gmail.com> writes:

> > "An inverse member does not have a corresponding column or, in case
> >  of a container, table in the resulting database schema. Instead,
> >  the column or table from the referenced object is used to retrieve
> >  the relationship information. Only ordered and set containers can
> >  be used for inverse members. If an inverse member is of an ordered
> >  container type, it is automatically marked as unordered."
> 
> What's the rationale for not enabling std::map but enabling std::set
> and 'ordered' containers?

The explanation is actually in the above passage I quoted from the
manual. The inverse container doesn't have its own table and thus
there is no place to store the map's key. The entries for this
container are "inferred" from the entries for the direct side of
the relationship. Section 6.2, "Bidirectional Relationships" in
the ODB manual has more information on this.

One way to make map "work" in your example would be to make the
other side inverse instead.

Boris

From marco.craveiro at gmail.com  Thu Jan 17 15:48:53 2013
From: marco.craveiro at gmail.com (Marco Craveiro)
Date: Thu Jan 17 15:34:12 2013
Subject: [odb-users] Using ODB with C++-11
Message-ID: <CAKRNd4wCLF14RrQ-SFp2Xa_8PaKZHW0uVSDZp1BFGnOC--y+tQ@mail.gmail.com>

Hi odb-users,

We're trying to add support for ODB to our domain generator dogen [1].
Dogen basically takes UML diagrams in Dia [2] and generates C++-11 code
from them. I did a first attempt which generates code like so:

https://github.com/kitanda/dogen/blob/master/projects/class_without_package/include/dogen/class_without_package/odb/class_1_odb.hpp
https://github.com/kitanda/dogen/blob/master/projects/class_without_package/include/dogen/class_without_package/types/class_1.hpp

I obtained ODB from here [3] and unpacked it in /opt/odb. I then read [4]
(I'm doing a second, more thorough read in case my initial shallow read
failed).

I then tried to use ODB on the generated code I got the following errors:

$ /opt/odb/bin/odb --std c++11 -d pgsql --generate-query --generate-schema
-I
/home/marco/Development/kitanda/dogen/projects/class_without_package/include/
class_without_package/include/dogen/class_without_package/odb/class_1_odb.hpp

I got the following errors:

In file included from
class_without_package/include/dogen/class_without_package/odb/class_1_odb.hpp:28:0:
/home/marco/Development/kitanda/dogen/projects/class_without_package/include/dogen/class_without_package/types/class_1.hpp:34:15:
error: variable 'dogen::class_without_package::class_1
dogen::class_without_package::final' has initializer but incomplete type
/home/marco/Development/kitanda/dogen/projects/class_without_package/include/dogen/class_without_package/types/class_1.hpp:35:1:
error: expected primary-expression before 'public'
/home/marco/Development/kitanda/dogen/projects/class_without_package/include/dogen/class_without_package/types/class_1.hpp:35:1:
error: expected '}' before 'public'
/home/marco/Development/kitanda/dogen/projects/class_without_package/include/dogen/class_without_package/types/class_1.hpp:35:1:
error: expected ',' or ';' before 'public'
/home/marco/Development/kitanda/dogen/projects/class_without_package/include/dogen/class_without_package/types/class_1.hpp:37:20:
error: expected ')' before '&&' token
/home/marco/Development/kitanda/dogen/projects/class_without_package/include/dogen/class_without_package/types/class_1.hpp:38:16:
error: expected constructor, destructor, or type conversion before '=' token
<snip>

As a layman analysis it seems like I'm not getting ODB to C++ 11 mode for
some reason, but can't see what I'm doing wrong. Can someone point out any
glaring mistakes?

Thanks for your time

Marco
-- 
So young, and already so unknown -- Pauli

blog: http://mcraveiro.blogspot.com

[1] https://github.com/kitanda/dogen
[2] https://live.gnome.org/Dia
[3]
http://www.codesynthesis.com/download/odb/2.1/odb-2.1.1-x86_64-linux-gnu.tar.bz2
[4]
http://www.codesynthesis.com/~boris/blog/2012/03/27/cxx11-support-in-odb/
From boris at codesynthesis.com  Fri Jan 18 04:03:11 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Jan 18 03:10:29 2013
Subject: [odb-users] Using ODB with C++-11
In-Reply-To: <CAKRNd4wCLF14RrQ-SFp2Xa_8PaKZHW0uVSDZp1BFGnOC--y+tQ@mail.gmail.com>
References: <CAKRNd4wCLF14RrQ-SFp2Xa_8PaKZHW0uVSDZp1BFGnOC--y+tQ@mail.gmail.com>
Message-ID: <boris.20130118105341@codesynthesis.com>

Hi Marco,

Marco Craveiro <marco.craveiro@gmail.com> writes:

> I got the following errors:
> 
> error: variable 'dogen::class_without_package::class_1
> dogen::class_without_package::final' has initializer but incomplete type

I took a look at your source code and it appears your using the 'final'
keyword:


> class class_1 final {

The problem is, the binary ODB package uses an old-ish version of GCC
(4.5.1 to be precise). While override control was only added in 4.7.

We are planning to upgrade to a newer version at some point, just
didn't have a chance to do that yet.

In the meantime, the best option for you would be to build the ODB
compiler from source. Seeing that you are using C++11, you must
have a fairly recent version of GCC already installed. It only
makes sense for ODB to also use this version. For details on how
to build ODB from source, see the INSTALL file that comes with
the package.

Boris

From marco.craveiro at gmail.com  Fri Jan 18 06:42:13 2013
From: marco.craveiro at gmail.com (Marco Craveiro)
Date: Fri Jan 18 06:27:28 2013
Subject: [odb-users] Using ODB with C++-11
In-Reply-To: <boris.20130118105341@codesynthesis.com>
References: <CAKRNd4wCLF14RrQ-SFp2Xa_8PaKZHW0uVSDZp1BFGnOC--y+tQ@mail.gmail.com>
	<boris.20130118105341@codesynthesis.com>
Message-ID: <CAKRNd4xxNLqkXU80HEbCw=v-LZWACzfj4coBGx0wUfWjJGyd2A@mail.gmail.com>

Boris,

I took a look at your source code and it appears your using the 'final'
> keyword:
>
> > class class_1 final {
>
> The problem is, the binary ODB package uses an old-ish version of GCC
> (4.5.1 to be precise). While override control was only added in 4.7.
>
>
Ah, I see.


> We are planning to upgrade to a newer version at some point, just
> didn't have a chance to do that yet.
>
> In the meantime, the best option for you would be to build the ODB
> compiler from source. Seeing that you are using C++11, you must
> have a fairly recent version of GCC already installed. It only
> makes sense for ODB to also use this version. For details on how
> to build ODB from source, see the INSTALL file that comes with
> the package.
>

Yes, we are using a 4.7 build we done ourselves for all of our supported
platforms. I'll look at your instructions.

Many thanks for your time.

Cheers
-- 
So young, and already so unknown -- Pauli

blog: http://mcraveiro.blogspot.com
From marco.craveiro at gmail.com  Fri Jan 18 09:53:55 2013
From: marco.craveiro at gmail.com (Marco Craveiro)
Date: Fri Jan 18 09:39:09 2013
Subject: [odb-users] Using ODB with C++-11
In-Reply-To: <CAKRNd4xxNLqkXU80HEbCw=v-LZWACzfj4coBGx0wUfWjJGyd2A@mail.gmail.com>
References: <CAKRNd4wCLF14RrQ-SFp2Xa_8PaKZHW0uVSDZp1BFGnOC--y+tQ@mail.gmail.com>
	<boris.20130118105341@codesynthesis.com>
	<CAKRNd4xxNLqkXU80HEbCw=v-LZWACzfj4coBGx0wUfWjJGyd2A@mail.gmail.com>
Message-ID: <CAKRNd4xA7hr5S8Q5cK4Yd=mmhmM=e_gOxmNUwzjt2ECGN9G3rA@mail.gmail.com>

Boris,

I have installed cutl, ODB compiler, ODB runtime, postgres support and the
boost profile as per INSTALL instructions. I have used the source packages
for version 2.1.1. They have been built against GCC-4.7 - I ended up using
the default debian GCC as the apt-get seemed easy enough. I now have a
working odb that does not choke on C++-11. Many thanks for your help with
this.

However, I'm now struggling with the following error:

odb --std c++11 -d pgsql --generate-query --generate-schema -I
/home/marco/Development/kitanda/dogen/projects/class_without_package/include/
-I /usr/local/pfh/include
class_without_package/include/dogen/class_without_package/odb/class_1_odb.hpp

class_without_package/include/dogen/class_without_package/odb/class_1_odb.hpp:37:43:
error: unknown db pragma an_attribute

The pragmas on my code are these:

#pragma db object(class_1)
#pragma db member(class_1::an_attribute_) an_attribute

To the untrained eye, they look similar enough to the hello world tutorial:

#pragma db object(person)
#pragma db member(person::email_) id

Can you shed some light on what I'm doing wrong?

Thanks for your time

Marco
-- 
So young, and already so unknown -- Pauli

blog: http://mcraveiro.blogspot.com
From davejohansen at gmail.com  Fri Jan 18 10:13:42 2013
From: davejohansen at gmail.com (Dave Johansen)
Date: Fri Jan 18 09:58:56 2013
Subject: [odb-users] gcc plugin support on RHEL/CentOS 5 and 6?
In-Reply-To: <boris.20130113122059@codesynthesis.com>
References: <CAAcYxUdAg9Djkdo6VkCQG4_7OJn3EL8nRFyQ36=ungcDgMSPaQ@mail.gmail.com>
	<boris.20130109154702@codesynthesis.com>
	<CAAcYxUcHwnLsxEzQfBoMOtgT5dpvmAjYXnMGEMd2oJ_0y7=m5Q@mail.gmail.com>
	<boris.20130109211244@codesynthesis.com>
	<CAAcYxUd8C__cAOsottdv6RhzWpUhvS_b8ZmKEmNxOb3bzMr0iQ@mail.gmail.com>
	<boris.20130110162553@codesynthesis.com>
	<CAAcYxUfSx1bXsSgzC31arnJNxtJytMFWDP=8JwkVvpOKeCkPTA@mail.gmail.com>
	<boris.20130111182456@codesynthesis.com>
	<CAAcYxUddBq1TGX0vKZks-hnbNP7LBZBbpTRWxN_K4BFshFf6-A@mail.gmail.com>
	<boris.20130113122059@codesynthesis.com>
Message-ID: <CAAcYxUeF9XE70+95EYARbrh3zFv=bRL0yboMLXJ1aRUvcyKMGw@mail.gmail.com>

On Sun, Jan 13, 2013 at 3:38 AM, Boris Kolpackov <boris@codesynthesis.com>wrote:

> Dave Johansen <davejohansen@gmail.com> writes:
>
> > RedHat is making GCC 4.7 available for RHEL 5/6, but it's not available
> as
> > part of the EPEL or any other standard source for CentOS:
> >
> http://www.redhat.com/summit/2012/pdf/2012-DevDay-How-To-Toolset-Newsome.pdf
>
> Thanks for sharing the link. I believe this is exactly what we need. It
> will be much, much better than building and packaging our own GCC. The
> end-users won't even have to use GCC 4.7 to build their application.
> They can continue using GCC 4.1/4.4 and the ODB compiler will under
> the hood use GCC 4.7 to do its work (so no need for that "enable ..."
> calls mentioned on the slides). In other words, the way I see this
> working from the user perspective:
>
> 1. Install GCC 4.7 .rpm from Developer Tools.
>
> 2. Install ODB compiler rpm (built with GCC 4.7).
>
> 3. Install ODB runtime .rpm's (built with GCC 4.1/4.4).
>
> 4. Build your application with GCC 4.1/4.4 without any concern for GCC 4.7
>    (of course, if you want to use 4.7, nothing prevents you from doing so).
>
> I did some Google'ing and there appears to be a CentOS build of Developer
> Tools:
>
> https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39506
>
> Also, someone is working on the same for Scientific Linux:
>
>
> http://www.mail-archive.com/scientific-linux-users@listserv.fnal.gov/msg12452.html
>
> And, it appears that plugin support is enabled! I see for CentOS there is
> this package:
>
> devtoolset-1.0-gcc-plugin-devel-4.7.0-5.2.el5.centos.x86_64.rpm
>
> Which I assume includes the plugin headers needed to build ODB (at least
> that's what a package with the same name in Fedora contains). I think we
> are all sorted.
>
> Boris
>

I agree that that would be a much simpler solution, but the issue is that
that is still a "testing only" build. I'm sure that's just part of the
standard warnings that they throw out for that sort of stuff and it would
work fine, but it would be nice if it was integrated into one of the
standard CentOS sources for RPMs and didn't require installing a random
testing repo. Maybe I'll see if I can help get that moved over to a
standard channel on CentOS as part of this effort.

Thanks,
Dave
From boris at codesynthesis.com  Fri Jan 18 11:26:03 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Jan 18 10:33:17 2013
Subject: [odb-users] Using ODB with C++-11
In-Reply-To: <CAKRNd4xA7hr5S8Q5cK4Yd=mmhmM=e_gOxmNUwzjt2ECGN9G3rA@mail.gmail.com>
References: <CAKRNd4wCLF14RrQ-SFp2Xa_8PaKZHW0uVSDZp1BFGnOC--y+tQ@mail.gmail.com>
	<boris.20130118105341@codesynthesis.com>
	<CAKRNd4xxNLqkXU80HEbCw=v-LZWACzfj4coBGx0wUfWjJGyd2A@mail.gmail.com>
	<CAKRNd4xA7hr5S8Q5cK4Yd=mmhmM=e_gOxmNUwzjt2ECGN9G3rA@mail.gmail.com>
Message-ID: <boris.20130118182354@codesynthesis.com>

Hi Marco,

Marco Craveiro <marco.craveiro@gmail.com> writes:

> The pragmas on my code are these:
> 
> #pragma db object(class_1)
> #pragma db member(class_1::an_attribute_) an_attribute
> 
> To the untrained eye, they look similar enough to the hello world tutorial:
> 
> #pragma db object(person)
> #pragma db member(person::email_) id

The 'id' pragma tells the ODB compiler that email_ data member is object
id. What would 'an_attribute' pragma tell the ODB compiler?

Boris

From marco.craveiro at gmail.com  Sat Jan 19 07:43:47 2013
From: marco.craveiro at gmail.com (Marco Craveiro)
Date: Sat Jan 19 07:28:54 2013
Subject: [odb-users] Using ODB with C++-11
In-Reply-To: <boris.20130118182354@codesynthesis.com>
References: <CAKRNd4wCLF14RrQ-SFp2Xa_8PaKZHW0uVSDZp1BFGnOC--y+tQ@mail.gmail.com>
	<boris.20130118105341@codesynthesis.com>
	<CAKRNd4xxNLqkXU80HEbCw=v-LZWACzfj4coBGx0wUfWjJGyd2A@mail.gmail.com>
	<CAKRNd4xA7hr5S8Q5cK4Yd=mmhmM=e_gOxmNUwzjt2ECGN9G3rA@mail.gmail.com>
	<boris.20130118182354@codesynthesis.com>
Message-ID: <CAKRNd4xTOoPLs+UvaFxCWdzZcV-tLokCAk78wKtKyUqujVuUfg@mail.gmail.com>

Boris,

The 'id' pragma tells the ODB compiler that email_ data member is object
> id. What would 'an_attribute' pragma tell the ODB compiler?
>
>
Ah yes, the old RTM deficit! :-) ok, had a good read now [1] and got the
basics to work, thanks a lot for your help. When I finish adding ODB
support to dogen I'll report back.

Cheers,

Marco
-- 
So young, and already so unknown -- Pauli

blog: http://mcraveiro.blogspot.com

[1] http://www.codesynthesis.com/products/odb/doc/manual.xhtml#12
From boris at codesynthesis.com  Sun Jan 20 09:00:46 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Jan 20 08:07:35 2013
Subject: [odb-users] Using ODB with C++-11
In-Reply-To: <CAKRNd4xTOoPLs+UvaFxCWdzZcV-tLokCAk78wKtKyUqujVuUfg@mail.gmail.com>
References: <CAKRNd4wCLF14RrQ-SFp2Xa_8PaKZHW0uVSDZp1BFGnOC--y+tQ@mail.gmail.com>
	<boris.20130118105341@codesynthesis.com>
	<CAKRNd4xxNLqkXU80HEbCw=v-LZWACzfj4coBGx0wUfWjJGyd2A@mail.gmail.com>
	<CAKRNd4xA7hr5S8Q5cK4Yd=mmhmM=e_gOxmNUwzjt2ECGN9G3rA@mail.gmail.com>
	<boris.20130118182354@codesynthesis.com>
	<CAKRNd4xTOoPLs+UvaFxCWdzZcV-tLokCAk78wKtKyUqujVuUfg@mail.gmail.com>
Message-ID: <boris.20130120155841@codesynthesis.com>

Hi Marco,

Marco Craveiro <marco.craveiro@gmail.com> writes:

> When I finish adding ODB support to dogen I'll report back.

That would be much appreciated. When Dogen is ready I would like
to add a link to the Wiki and maybe write a note on my blog. So
do let us know.

Boris

From Davide.Anastasia at qualitycapital.com  Mon Jan 21 06:59:26 2013
From: Davide.Anastasia at qualitycapital.com (Davide Anastasia)
Date: Mon Jan 21 06:44:16 2013
Subject: [odb-users] Thoughts about GCC as front end for the ODB Compiler
Message-ID: <021C07AF2F2DAE4F9F4B7B9D43B7C505B338A4@THHSLE14MBX5.hslive.net>

Hi,
I was wondering whether Clang++/LLVM frontend could be used in place of GCC as frontend for the ODB compiler. Would that make the ODB compiler simpler to compile/extend?
Just a quick thought, not sure whether it makes sense and it has some implication on the framework.

Best,
Davide
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5317 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/odb-users/attachments/20130121/1084891d/winmail.bin
From boris at codesynthesis.com  Mon Jan 21 08:03:24 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Jan 21 07:09:58 2013
Subject: [odb-users] Thoughts about GCC as front end for the ODB Compiler
In-Reply-To: <021C07AF2F2DAE4F9F4B7B9D43B7C505B338A4@THHSLE14MBX5.hslive.net>
References: <021C07AF2F2DAE4F9F4B7B9D43B7C505B338A4@THHSLE14MBX5.hslive.net>
Message-ID: <boris.20130121145246@codesynthesis.com>

Hi Davide,

Davide Anastasia <Davide.Anastasia@qualitycapital.com> writes:

> I was wondering whether Clang++/LLVM frontend could be used in place
> of GCC as frontend for the ODB compiler.

Theoretically, yes. However, this will most likely involve a non-trivial
amount of work.


> Would that make the ODB compiler simpler to compile/extend?

I don't think it will make any difference extensibility-wise. As for
building the ODB compiler, I think it will make it more difficult,
not easier.

On fairly recent GNU/Linux distributions building the ODB compiler
is actually a fairly easy process: (1) install plugin headers from
the distribution's repository, (2) build libcutl, and (3) build odb.

In contrast, last time I checked, at least on Debian, Clang headers
and libraries weren't packaged. So you would need to build CLang
from source.

On Windows it may be easier to build the ODB compiler itself with
Clang (if we supported it, that is). However, the whole toolchain
(e.g., the standard libraries, system headers, etc.) for Clang on
Windows is a lot less mature than that of GCC (MinGW). So while
building the ODB compiler itself might be easier, getting the whole
thing to work properly might actually be a lot harder.

Boris

From tony at rightsoft.com.au  Tue Jan 22 09:49:23 2013
From: tony at rightsoft.com.au (Tony Rietwyk)
Date: Tue Jan 22 09:34:05 2013
Subject: [odb-users] RE: about adding support of firebird to ODB
In-Reply-To: <007D20F4-8264-4B9C-916F-63F212813B7D@gmail.com>
References: <007D20F4-8264-4B9C-916F-63F212813B7D@gmail.com>
Message-ID: <002d01cdf8af$ab39a760$01acf620$@rightsoft.com.au>

> Sent: Wednesday, 23 January 2013 12:38 AM
> To: tony.rietwyk@rightsoft.com.au
> 
> Hi,
> 
>  I saw your post about this topic, and we need this function too.
> 
> Do you have any progress on it, or we can develop it together?
> 
> Thanks.

Hi Sun, 

Best to keep questions on the list, so that others can see the results.  

I did not pursue ODB any further 18 months ago.  I would suggest to use the
qt connector if you can use Qt.  Otherwise, converting odb\sqlite to use
IBPP objects instead looks straightforward - and is much easier than the
Firebird C API directly.  It might be hard to map Firebird's transactions,
to those required by odb.  See http://www.ibpp.org/. 

Tony.






From tony.rietwyk at rightsoft.com.au  Tue Jan 22 09:41:15 2013
From: tony.rietwyk at rightsoft.com.au (Tony Rietwyk)
Date: Wed Jan 23 02:25:32 2013
Subject: [odb-users] RE: about adding support of firebird to ODB
In-Reply-To: <007D20F4-8264-4B9C-916F-63F212813B7D@gmail.com>
References: <007D20F4-8264-4B9C-916F-63F212813B7D@gmail.com>
Message-ID: <002c01cdf8ae$88a22ca0$99e685e0$@rightsoft.com.au>

> Sent: Wednesday, 23 January 2013 12:38 AM
> To: tony.rietwyk@rightsoft.com.au
> 
> Hi,
> 
>  I saw your post about this topic, and we need this function too.
> 
> Do you have any progress on it, or we can develop it together?
> 
> Thanks.

Hi Sun, 

Best to keep questions on the list, so that others can see the results.  

I did not pursue ODB any further 18 months ago.  I would suggest to use the
qt connector if you can use Qt.  Otherwise, converting odb\sqlite to use
IBPP objects instead looks straightforward - and is much easier than the
Firebird API directly.  It might be hard to map Firebird's transactions, to
those required by odb.  See http://www.ibpp.org/. 

Tony.






From boris at codesynthesis.com  Wed Jan 23 07:26:42 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jan 23 06:32:54 2013
Subject: [odb-users] Re: Gentoo ODB package
In-Reply-To: <20130123102133.dfd48d31a20af1d60d4737d7@zotac.lan>
References: <20130123102133.dfd48d31a20af1d60d4737d7@zotac.lan>
Message-ID: <boris.20130123135408@codesynthesis.com>

Hi Hugo,

I've CC'ed the odb-users mailing list in case anyone else is interested
in ODB packages for Gentoo.

Hugo.Mildenberger@web.de <Hugo.Mildenberger@web.de> writes:

> I'm thinking about to write a Gentoo package for ODB.

That would be fantastic! I would be happy to help if you run into
any issues. Also, when you are done, please send a note to odb-users
so that we can mention your work on the website, etc.


> However, Gentoo requires the package developer to name the licences,
> which in turn are stored verbatim somewhere on disk. Hence, I checked
> http://www.codesynthesis.com/products/odb/license.xhtml and encountered
> several problems: 
> 
>  1.) odb-2.1.1 sources are distributed with GPLv3, whereas your licence
>      page above states ODB would be licensed under GPLv2.
>  2.) The text or version of CPL is not available
>  3.) The text of NCUEL is not available
>  4.) The text of FPL is not available

Ok, let me try to explain how ODB is licensed. The important thing to
keep in mind is that ODB consists of multiple components, and they have
different licenses, specifically:

- odb

  This this the ODB compiler itself. Because it is implemented as a
  GCC plugin, we didn't have much choice other than license it under
  the GPLv3 (the same license as GCC). Note, however, that the source
  code produced by the ODB compiler is not copyrighted.

- libodb
  libodb-{mysql, sqlite, pgsql}
  libodb-{qt, boost}

  These are the common runtime, database runtimes for the open source
  databases, as well as the profile libraries for Qt and Boost,
  respectively. All of these are licensed under the GPLv2.

  Because the code produced by the ODB compiler is not copyrighted and
  these runtimes are licensed under the GPLv2, from the point of view
  of the application developer who uses ODB with one of the open source
  database, ODB is under GPLv2. Which is why we say ODB is GPLv2 in the
  introduction.

- libodb-{oracle, mssql}

  These are database runtimes for the commercial databases and are licensed
  under our own, non-open source Non-Commercial Use or Evaluation License
  (NCUEL). The text of NCUEL comes with the above packages and is also
  available online:

  http://www.codesynthesis.com/licenses/ncuel.txt

Now, some people don't want to be bound by the terms of the GPLv2/NCUEL.
In this case, there are two options:

1. If the object model is fairly small (the generated database support
   code is under 10,000 lines), then they can use ODB under the Free
   Proprietary License (FPL) which doesn't have any of the GPLv2
   restrictions.

   We don't publish the text of FPL and every individual/company will
   need to contact us to get it.

2. Otherwise, there is the Commercial Proprietary License (CPL). Again,
   we do not publish its text.

3. For completeness, we are also open to granting license exceptions
   to other open source projects that wish to use ODB but are
   incompatible with GPLv2. For more information on this, see the blog
   post on the topic:

   http://www.codesynthesis.com/~boris/blog/2012/08/22/odb-license-exception/
   
Also, here are my thoughts on packaging ODB for open source GNU/Linux 
distributions like Gentoo, Debian/Ubuntu, Fedora, etc.:

1. Don't package libodb-{oracle, mssql}. These are not licensed under
   the open source license and probably won't be accepted to the
   repository. Also, their prerequisites are not open source either
   (Oracle OCI, SQL Server Native Client) so they won't be in the
   repository.

2. For the ODB compiler, state the license as GPLv3 and include its
   text in the package.

3. For the runtimes, state the license as GPLv2 and include its text
   in the package. You can also mentioned that other licenses are
   available and give a link to:

   http://www.codesynthesis.com/products/odb/license.xhtml


> Regarding FPL, I tend to solve the problem by creating a file
> referring the reader to your licence site.

Yes, that sounds good and is pretty much what I suggested in (3)
above.

Boris

From boris at codesynthesis.com  Wed Jan 23 07:58:39 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jan 23 07:04:48 2013
Subject: [odb-users] RE: about adding support of firebird to ODB
In-Reply-To: <002c01cdf8ae$88a22ca0$99e685e0$@rightsoft.com.au>
References: <007D20F4-8264-4B9C-916F-63F212813B7D@gmail.com>
	<002c01cdf8ae$88a22ca0$99e685e0$@rightsoft.com.au>
Message-ID: <boris.20130123144814@codesynthesis.com>

Hi Tony,

Tony Rietwyk <tony.rietwyk@rightsoft.com.au> writes:

> Best to keep questions on the list, so that others can see the results.

Yes, thanks for CC'ing odb-users, much appreciated.


> Otherwise, converting odb\sqlite to use IBPP objects instead looks
> straightforward - and is much easier than the Firebird API directly.

I took a look at IBPP samples and the API looks fairly clean. However,
generally, in ODB, we prefer to use the low-level, native C API for
the following reasons:

1. No extra dependencies.

2. Smaller footprint and better performance (no extra "abstraction"
   layer overhead).

3. Access to all the features exposed by the native API.


> It might be hard to map Firebird's transactions, to those required by
> odb.

Hm, can you elaborate? Looking at IBPP sample code, their transaction
semantics is pretty much exactly the same as in ODB. So if they could
wrap the C API like this then so should we.

In general, I think IBPP will be a great reference for how to handle
things like transactions, prepared queries, etc.

Boris

From tony.rietwyk at rightsoft.com.au  Wed Jan 23 18:14:51 2013
From: tony.rietwyk at rightsoft.com.au (Tony Rietwyk)
Date: Thu Jan 24 02:03:39 2013
Subject: [odb-users] RE: about adding support of firebird to ODB
In-Reply-To: <boris.20130123144814@codesynthesis.com>
References: <007D20F4-8264-4B9C-916F-63F212813B7D@gmail.com>
	<002c01cdf8ae$88a22ca0$99e685e0$@rightsoft.com.au>
	<boris.20130123144814@codesynthesis.com>
Message-ID: <001b01cdf9bf$72472f70$56d58e50$@rightsoft.com.au>

Hi Boris, 

> > It might be hard to map Firebird's transactions, to those required by
> > odb.
> 
> Hm, can you elaborate? Looking at IBPP sample code, their transaction
> semantics is pretty much exactly the same as in ODB. So if they could wrap
> the C API like this then so should we.

Nothing specific.  I didn't get into ODB well enough to see the similarities
in transaction levels.  I just assumed it would be one of those tricky
aspects to contend with when taking on any DBMS.  

> In general, I think IBPP will be a great reference for how to handle
things like
> transactions, prepared queries, etc.

Good to hear that.  

Regards, 

Tony. 


From almogco at gmail.com  Fri Jan 25 22:49:27 2013
From: almogco at gmail.com (Almog Cohen)
Date: Sat Jan 26 05:24:25 2013
Subject: [odb-users] ODB compiler does not check up-to-date
Message-ID: <B42DE908-F3F1-4F15-B529-202622C9376C@gmail.com>

Hi,

it seems that when using VS2010 -> Custom build scripts for compiling using the ODB compiler, the compiler does not check if the files are up-to-date before compiling and just builds them all.
this significantly extends build time in big projects.

Almog.



From boris at codesynthesis.com  Mon Jan 28 08:09:02 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Jan 28 07:13:59 2013
Subject: [odb-users] ODB compiler does not check up-to-date
In-Reply-To: <B42DE908-F3F1-4F15-B529-202622C9376C@gmail.com>
References: <B42DE908-F3F1-4F15-B529-202622C9376C@gmail.com>
Message-ID: <boris.20130128145649@codesynthesis.com>

Hi Almog,

Almog Cohen <almogco@gmail.com> writes:

> it seems that when using VS2010 -> Custom build scripts for compiling
> using the ODB compiler, the compiler does not check if the files are
> up-to-date before compiling and just builds them all. this significantly
> extends build time in big projects.

Hm, this is strange. We don't observe this behavior in our examples
and tests. To verify, I tried the following steps:

1. Open the examples solution found in the odb-examples package.

2. Build the 'hello' example. Since this is the clean build, as
   expected, everything is compiled (i.e., the ODB compiler is
   invoked on hello.hxx, etc).

3. Build the example again. This time, again as expected, nothing
   is compiled (i.e., no ODB compiler execution) and VC++ simply
   says that everything is up-to-date.

4. Modify hello.hxx and build the example again. This time, again
   as expected, ODB compiler is invoked on hello.hxx.

So for me everything works as expected. Can you try the examples
and see if it works for you?

Note also that it is not the ODB compiler that checks whether
everything is up to date. Rather, it is the VC++ IDE. And the
way it decides whether it needs to run the custom build step
is by comparing the modification dates of the files mentioned
in the "Outputs" fields of the Custom Build dialog to that of
the header file.

So if you do not specify the correct output files, you will most
likely get constant rebuilds. Specifically, for the hello.hxx
header this field should contain (provided you haven't changed
the file suffixes):

hello-odb.hxx;hello-odb.ixx;hello-odb.cxx

That is, the generated file names are separated with the
semicolon.

Boris

From almogco at gmail.com  Mon Jan 28 20:00:03 2013
From: almogco at gmail.com (Almog Cohen)
Date: Tue Jan 29 00:17:43 2013
Subject: [odb-users] ODB compiler does not check up-to-date
In-Reply-To: <boris.20130128145649@codesynthesis.com>
References: <B42DE908-F3F1-4F15-B529-202622C9376C@gmail.com>
	<boris.20130128145649@codesynthesis.com>
Message-ID: <51086308-0B3C-47B8-8B19-E9C76C72F4F3@gmail.com>

Hi Boris,

Thank you for your reply.
You are right, it was my mistake.
I modified the syntax from the example to fit any general header:
%(Filename)-odb.hxx;%(Filename)-odb.ixx;%(Filename)-odb.cxx;%(Outputs)
and i accidentally wrote %(Filename)-odb.h instead of hxx.

thanks again.

On Jan 28, 2013, at 5:09 AM, Boris Kolpackov <boris@codesynthesis.com> wrote:

> Hi Almog,
> 
> Almog Cohen <almogco@gmail.com> writes:
> 
>> it seems that when using VS2010 -> Custom build scripts for compiling
>> using the ODB compiler, the compiler does not check if the files are
>> up-to-date before compiling and just builds them all. this significantly
>> extends build time in big projects.
> 
> Hm, this is strange. We don't observe this behavior in our examples
> and tests. To verify, I tried the following steps:
> 
> 1. Open the examples solution found in the odb-examples package.
> 
> 2. Build the 'hello' example. Since this is the clean build, as
>   expected, everything is compiled (i.e., the ODB compiler is
>   invoked on hello.hxx, etc).
> 
> 3. Build the example again. This time, again as expected, nothing
>   is compiled (i.e., no ODB compiler execution) and VC++ simply
>   says that everything is up-to-date.
> 
> 4. Modify hello.hxx and build the example again. This time, again
>   as expected, ODB compiler is invoked on hello.hxx.
> 
> So for me everything works as expected. Can you try the examples
> and see if it works for you?
> 
> Note also that it is not the ODB compiler that checks whether
> everything is up to date. Rather, it is the VC++ IDE. And the
> way it decides whether it needs to run the custom build step
> is by comparing the modification dates of the files mentioned
> in the "Outputs" fields of the Custom Build dialog to that of
> the header file.
> 
> So if you do not specify the correct output files, you will most
> likely get constant rebuilds. Specifically, for the hello.hxx
> header this field should contain (provided you haven't changed
> the file suffixes):
> 
> hello-odb.hxx;hello-odb.ixx;hello-odb.cxx
> 
> That is, the generated file names are separated with the
> semicolon.
> 
> Boris

From Hugo.Mildenberger at web.de  Wed Jan 30 07:09:37 2013
From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de)
Date: Wed Jan 30 06:53:18 2013
Subject: [odb-users] odb-tests-2.1.1 failed with mariadb-5.1.66
Message-ID: <20130130130937.c9d021503903f5a726c1f542@zotac.lan>


[...]
Making check in containers
make[3]: Entering directory `/var/tmp/portage/dev-db/odb-2.1.1/work/odb-tests-2.1.1-mysql/qt/common/containers'
make  check-am
make[4]: Entering directory `/var/tmp/portage/dev-db/odb-2.1.1/work/odb-tests-2.1.1-mysql/qt/common/containers'
make  check-TESTS
make[5]: Entering directory `/var/tmp/portage/dev-db/odb-2.1.1/work/odb-tests-2.1.1-mysql/qt/common/containers'
ERROR 1071 (42000) at line 57: Specified key was too long; max key length is 767 bytes
FAIL: ../../../tester
============================================
1 of 1 test failed
Please report to odb-users@codesynthesis.com
============================================


From boris at codesynthesis.com  Wed Jan 30 09:57:57 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Jan 30 09:02:25 2013
Subject: [odb-users] odb-tests-2.1.1 failed with mariadb-5.1.66
In-Reply-To: <20130130130937.c9d021503903f5a726c1f542@zotac.lan>
References: <20130130130937.c9d021503903f5a726c1f542@zotac.lan>
Message-ID: <boris.20130130165258@codesynthesis.com>

Hi Hugo,

Hugo.Mildenberger@web.de <Hugo.Mildenberger@web.de> writes:

> ERROR 1071 (42000) at line 57: Specified key was too long; max key 
> length is 767 bytes

Hm, the keys in the test are created as VARCHAR(256). It seems like
this is a character set issue. I think your setup of MariaDB uses
UTF-8 by default which requires 3 bytes per character. This post
has more details:

http://www.xaprb.com/blog/2006/04/17/max-key-length-in-mysql/

Can you run the following query and show us the output:

show variables like '%char%';

Here is mine on which all the tests run fine, for reference:

+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     |
| character_set_connection | latin1                     |
| character_set_database   | latin1                     |
| character_set_filesystem | binary                     |
| character_set_results    | latin1                     |
| character_set_server     | latin1                     |
| character_set_system     | utf8                       |
| character_sets_dir       | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+

Boris

From Hugo.Mildenberger at web.de  Wed Jan 30 16:15:47 2013
From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de)
Date: Wed Jan 30 15:59:24 2013
Subject: [odb-users] another test from odb-tests-2.1.1 fails with
	mariadb-5.5.28a
Message-ID: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan>

Hi Boris,

here is another failed test, this time using mariadb-5.5.28a. 
Maybe this is a reflection of another mariadb bug? 


make  check-TESTS
make[2]: Entering directory `/var/tmp/portage/dev-db/odb-2.1.1/work/odb-tests-2.1.1-mysql/boost/mysql/date-time'
./driver --options-file ../../../db.options
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::gregorian::bad_day_of_month> >'
  what():  Day of month value is out of range 1..31
./../../../tester: line 39: 31551 Aborted                 (core dumped) ./driver --options-file "$top_builddir/db.options" > test.out
FAIL: ../../../tester
============================================
1 of 1 test failed
Please report to odb-users@codesynthesis.com
============================================

# ldd odb-tests-2.1.1-mysql/boost/mysql/date-time/.libs/driver
        linux-vdso.so.1 
        libcommon.so.0 => not found
        libodb-mysql-2.1.so => /usr/lib64/libodb-mysql-2.1.so 
        libodb-boost-2.1.so => /usr/lib64/libodb-boost-2.1.so 
        libodb-2.1.so => /usr/lib64/libodb-2.1.so 
        libpthread.so.0 => /lib64/libpthread.so.0 
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libstdc++.so.6 
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/libgcc_s.so.1 
        libc.so.6 => /lib64/libc.so.6 
        libmysqlclient.so.18 => /usr/lib64/libmysqlclient.so.18 
        /lib64/ld-linux-x86-64.so.2 
        libm.so.6 => /lib64/libm.so.6 
        libz.so.1 => /lib64/libz.so.1 
        libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 
        libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 
        libdl.so.2 => /lib64/libdl.so.2 
        librt.so.1 => /lib64/librt.so.1 


Here is some more info. The code was compiled with -O0 in order to be able to display
any variable contents.

# gdb /var/tmp/portage/dev-db/odb-2.1.1/work/odb-tests-2.1.1-mysql/boost/mysql/date-time/.libs/driver --core=250-250-driver.core 
[...]
Program terminated with signal 6, Aborted.
#0  0x00000324ddb39f75 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63
63	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb)
(gdb) bt
#0  0x00000324ddb39f75 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63
#1  0x00000324ddb3b3eb in __GI_abort () at abort.c:90
#2  0x00000324de17d43d in __gnu_cxx::__verbose_terminate_handler ()
    at /usr/src/debug/sys-devel/gcc-4.6.3/gcc-4.6.3/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00000324de17b5f6 in __cxxabiv1::__terminate (handler=<optimized out>)
    at /usr/src/debug/sys-devel/gcc-4.6.3/gcc-4.6.3/libstdc++-v3/libsupc++/eh_terminate.cc:40
#4  0x00000324de17b623 in std::terminate ()
    at /usr/src/debug/sys-devel/gcc-4.6.3/gcc-4.6.3/libstdc++-v3/libsupc++/eh_terminate.cc:50
#5  0x00000324de17b71e in __cxxabiv1::__cxa_throw (obj=<optimized out>, tinfo=<optimized out>, dest=<optimized out>)
    at /usr/src/debug/sys-devel/gcc-4.6.3/gcc-4.6.3/libstdc++-v3/libsupc++/eh_throw.cc:83
#6  0x0000006959f8e981 in boost::throw_exception<boost::gregorian::bad_day_of_month> (e=...)
    at /usr/include/boost/throw_exception.hpp:67
#7  0x0000006959f92d81 in boost::CV::simple_exception_policy<unsigned short, (unsigned short)1, (unsigned short)31, boost::gregorian::bad_day_of_month>::on_error () at /usr/include/boost/date_time/constrained_value.hpp:110
#8  0x0000006959f90013 in boost::CV::constrained_value<boost::CV::simple_exception_policy<unsigned short, (unsigned short)1, (unsigned short)31, boost::gregorian::bad_day_of_month> >::assign (this=0x3f388a974d0, value=0)
    at /usr/include/boost/date_time/constrained_value.hpp:69
#9  0x0000006959f8e14d in boost::CV::constrained_value<boost::CV::simple_exception_policy<unsigned short, 1u, 31u, boost::gregorian::bad_day_of_month> >::constrained_value (this=0x3f388a974d0, value=0)
    at /usr/include/boost/date_time/constrained_value.hpp:48
#10 0x0000006959f8d2cd in boost::gregorian::greg_day::greg_day (this=0x3f388a974d0, day_of_month=0)
    at /usr/include/boost/date_time/gregorian/greg_day.hpp:44
#11 0x0000006959f9cccd in odb::mysql::default_value_traits<boost::posix_time::ptime, (odb::mysql::database_type_id)13>::set_value (v=..., i=..., is_null=false) at /usr/include/odb/boost/date-time/mysql/posix-time-traits.hxx:39
#12 0x0000006959f98fef in odb::access::object_traits<object>::times_traits::init (j=@0x3f388a97600: 0, v=..., i=..., db=
    0x695d2f8c50) at test-odb.cxx:492
#13 0x0000006959f991c6 in odb::access::object_traits<object>::times_traits::load_all (i=@0x3f388a97600: 0, v=..., 
    d=0x695d315200) at test-odb.cxx:526
#14 0x0000006959fa2f19 in odb::ordered_functions<unsigned long, boost::posix_time::ptime>::load_all (this=0x695d315208, 
    next_index=@0x3f388a97600: 0, next_value=...) at /usr/include/odb/container-traits.hxx:57
#15 0x0000006959f9fb62 in odb::access::container_traits<std::vector<boost::posix_time::ptime, std::allocator<boost::posix_time::ptime> > >::load (c=std::vector of length 1, capacity 1 = {...}, more=true, f=...)
    at /usr/include/odb/std-vector-traits.hxx:46
#16 0x0000006959f995a1 in odb::access::object_traits<object>::times_traits::load (
    c=std::vector of length 1, capacity 1 = {...}, id=..., sts=...) at test-odb.cxx:597
#17 0x0000006959f9c555 in odb::access::object_traits<object>::load_ (sts=..., obj=...) at test-odb.cxx:1817
#18 0x0000006959f9beaf in odb::access::object_traits<object>::find (db=..., id=@0x3f388a97810: 1) at test-odb.cxx:1682
#19 0x0000006959f92c66 in odb::database::find<object> (this=0x695d2f8c50, id=@0x3f388a97810: 1)
    at /usr/include/odb/database.ixx:117
#20 0x0000006959f8fd7f in odb::database::load<object> (this=0x695d2f8c50, id=@0x3f388a97810: 1)
    at /usr/include/odb/database.txx:61
#21 0x0000006959f8bed9 in main (argc=3, argv=0x3f388a97d78) at driver.cxx:80

From Hugo.Mildenberger at web.de  Thu Jan 31 04:56:54 2013
From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de)
Date: Thu Jan 31 04:40:27 2013
Subject: [odb-users] another test from odb-tests-2.1.1 fails with
	mariadb-5.5.28a
In-Reply-To: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan>
References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan>
Message-ID: <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan>

I believe this database content is related to the boost/mysql/date-time test:

$ mysql -u test --database test;
Server version: 5.5.28a-MariaDB-log Source distribution

MariaDB [test]> select * from boost_mysql_dt_object_dates;
+-----------+-------+------------+
| object_id | index | value      |
+-----------+-------+------------+
|         1 |     0 | 2013-01-31 |
|         1 |     1 | NULL       |
|         1 |     2 | 9999-12-31 |
|         1 |     3 | 1400-01-01 |
+-----------+-------+------------+
4 rows in set (0.00 sec)

MariaDB [test]> select * from boost_mysql_dt_object_durations;
+-----------+-------+----------+
| object_id | index | value    |
+-----------+-------+----------+
|         1 |     0 | 00:00:00 |
|         1 |     1 | 00:00:00 |
|         1 |     2 | NULL     |
+-----------+-------+----------+
3 rows in set (0.00 sec)


MariaDB [test]> select * from boost_mysql_dt_object_times;
+-----------+-------+---------------------+
| object_id | index | value               |
+-----------+-------+---------------------+
|         1 |     0 | 0000-00-00 00:00:00 |
|         1 |     1 | NULL                |
|         1 |     2 | 0000-00-00 00:00:00 |
|         1 |     3 | 0000-00-00 00:00:00 |
+-----------+-------+---------------------+
4 rows in set (0.00 sec)


MariaDB [test]> select * from boost_mysql_dt_object_timestamps;
+-----------+-------+---------------------+
| object_id | index | value               |
+-----------+-------+---------------------+
|         1 |     0 | 0000-00-00 00:00:00 |
|         1 |     1 | NULL                |
+-----------+-------+---------------------+
2 rows in set (0.00 sec)



From boris at codesynthesis.com  Thu Jan 31 07:31:37 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Jan 31 06:35:53 2013
Subject: [odb-users] odb-tests-2.1.1 failed with mariadb-5.1.66
In-Reply-To: <20130130223750.10effa928e310245062d5570@zotac.lan>
References: <20130130130937.c9d021503903f5a726c1f542@zotac.lan>
	<boris.20130130165258@codesynthesis.com>
	<20130130223750.10effa928e310245062d5570@zotac.lan>
Message-ID: <boris.20130131142802@codesynthesis.com>

Hi Hugo,

Please keep the odb-users mailing list CC'ed to your replies.

Hugo.Mildenberger@web.de <Hugo.Mildenberger@web.de> writes:

> Server version: 5.1.66-MariaDB-log Gentoo Linux mariadb-5.1.66
> 
> MariaDB [test]>  show variables like '%char%';
> +--------------------------+----------------------------+
> | Variable_name            | Value                      |
> +--------------------------+----------------------------+
> | character_set_client     | utf8                       |
> | character_set_connection | utf8                       |
> | character_set_database   | utf8                       |
> | character_set_filesystem | binary                     |
> | character_set_results    | utf8                       |
> | character_set_server     | utf8                       |
> | character_set_system     | utf8                       |
> | character_sets_dir       | /usr/share/mysql/charsets/ |
> +--------------------------+----------------------------+

Thanks, that confirms it. I was also able to reproduce this
issue on MySQL by creating a table with the default charset
set to UTF-8. Further digging revealed that we already fixed
this for std::string but forgot to update the default mapping
for QString. Here is the patch:

http://scm.codesynthesis.com/?p=odb/libodb-qt.git;a=patch;h=5ddc3cc84883aef3fbb5ab8991ad36c0185404ac

And thanks for reporting this.

Boris

From boris at codesynthesis.com  Thu Jan 31 07:55:38 2013
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Jan 31 06:59:52 2013
Subject: [odb-users] another test from odb-tests-2.1.1 fails with
	mariadb-5.5.28a
In-Reply-To: <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan>
References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan>
	<20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan>
Message-ID: <boris.20130131144839@codesynthesis.com>

Hi Hugo,

Hugo.Mildenberger@web.de <Hugo.Mildenberger@web.de> writes:

> MariaDB [test]> select * from boost_mysql_dt_object_times;
> +-----------+-------+---------------------+
> | object_id | index | value               |
> +-----------+-------+---------------------+
> |         1 |     0 | 0000-00-00 00:00:00 |
> |         1 |     1 | NULL                |
> |         1 |     2 | 0000-00-00 00:00:00 |
> |         1 |     3 | 0000-00-00 00:00:00 |
> +-----------+-------+---------------------+

Yes, these value are definitely bogus. For some reason MariaDB cannot
store date-time values the same way as MySQL can (i.e., via the
MYSQL_TIME struct).

I looked around MariaDB website but couldn't find any documentation
for the C API (do they expect people to just use MySQL's manual?).
They also say "MariaDB is a binary drop in replacement for MySQL".
Hm, apparently not.

Have you tried it with MariaDB 5.1?

Boris

From Hugo.Mildenberger at web.de  Thu Jan 31 11:08:23 2013
From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de)
Date: Thu Jan 31 10:51:55 2013
Subject: [odb-users] another test from odb-tests-2.1.1 fails with
	mariadb-5.5.28a
In-Reply-To: <boris.20130131144839@codesynthesis.com>
References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan>
	<20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan>
	<boris.20130131144839@codesynthesis.com>
Message-ID: <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan>

Hi Boris,


 On Thu, 31 Jan 2013 14:55:38 +0200
 Boris Kolpackov <boris@codesynthesis.com> wrote:

 > I looked around MariaDB website but couldn't find any documentation
 > for the C API (do they expect people to just use MySQL's manual?).

Obviously. In the mariadb-5.5.28a/Docs/mysql.info file, they state that 
one should go to http://dev.mysql.com/doc for the MySQL reference manual,
and to http://kb.askmonty.org for the MariaDB manuals. There is 
in fact a page for the MariaDB APIs (although predominantly linking to empty 
documents): 

	https://kb.askmonty.org/en/using-mariadb-with-your-programs-api

However, there is a link to a sparsely written client API documentation. 


 > Have you tried it with MariaDB 5.1?

Yes. After having included the fix you provided for the QString/utf8 issue, 
the test suite completed successfully with MariaDB 5.1.66.


Hugo