From boris at codesynthesis.com  Tue Mar  1 10:27:53 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar  1 10:27:55 2016
Subject: [odb-users] query_one assertion fail since postgres update
In-Reply-To: <CAGj2=aVUOODae3YeVARvFCykaAmkpDL2K+cLWP73tnX68u1+kw@mail.gmail.com>
References: <CAGj2=aVUOODae3YeVARvFCykaAmkpDL2K+cLWP73tnX68u1+kw@mail.gmail.com>
Message-ID: <boris.20160301172006@codesynthesis.com>

Hi Michael,

Michael Mart?n Moro <sexymimi64@gmail.com> writes:

> I'm running Archlinux here, and recently we've had an update of Postgresql
> (the current version is 9.5.1).
> There seems to be an issue with this new version and odb's `query_one`
> method. Everything else works fine, afaik, but each use of `query_one` in
> my application fails an assertion when I use 9.5.1 libs and database.
> 
> I can perhaps help in fixing this issue, but I have no idea if it's already
> been reported (Archlinux made the update a few days ago already).
> 
> The failing assertion is the following:
> 
> /usr/include/odb/result.txx:36: bool odb::result<T>::one(T&) [with T =
> User]: Assertion `++i == end ()' failed.

My initial thought was that there is something "new" in PG 9.5 (and/or
its libpq client library) that causes this. So I have installed 9.5.1 from
the PG's apt repository and ran the entire ODB test suite (which includes
tests for query_one(); see common/quiery/one). No problems.

The only other difference between our setups is that I am using the latest
development version of ODB. If you would like to rule this out, you can try
the pre-release:

http://codesynthesis.com/~boris/tmp/odb/pre-release/

Failed that, I will need a test case that reproduces the problem. For
reference, here are my versions of the client libraries:

libpq5    9.5.1-1.pgdg14.04+1
libpq-dev 9.5.1-1.pgdg14.04+1

Boris

From henning.becker at apworks.de  Fri Mar  4 15:32:49 2016
From: henning.becker at apworks.de (Henning Becker)
Date: Fri Mar  4 15:33:00 2016
Subject: [odb-users] Persist container derived class as value type
Message-ID: <16565700.Bz92fURMOr@tegilbor.lan>

Hi,
I'm trying to persist QPolygon from Qt as a value type. QPolygon inherits from 
QVector<QPoint> and no data will be lost, if it is handled just as a 
QVector<QPoint>.

I have defined QPoint as a composite value type:
#pragma db value(QPoint) transient
#pragma db member(QPoint::x_) virtual(int) get(x) set(setX)
#pragma db member(QPoint::y_) virtual(int) get(y) set(setY)

But how can I make odb handle QPolygon as a QVector<QPoint>?

Thanks,
Henning

-- 
_______________________________________
 
Henning Becker

Development Engineer

AIRBUS APWORKS GmbH
Willy-Messerschmitt-Str. 1
82024 Taufkirchen - Germany 
T: +49 (0) 89 607 29771  
F: +49 (0) 89 607 28239  
M: +49 (0) 174 9818097  
henning.becker@apworks.de 

AIRBUS APWORKS GmbH
Registered Office: Ottobrunn
District Court of Munich: HRB 141734
Managing Director: Joachim Zettler
Internet: www.apworks.de
_______________________________________

From boris at codesynthesis.com  Mon Mar  7 09:03:43 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Mar  7 09:03:43 2016
Subject: [odb-users] Persist container derived class as value type
In-Reply-To: <16565700.Bz92fURMOr@tegilbor.lan>
References: <16565700.Bz92fURMOr@tegilbor.lan>
Message-ID: <boris.20160307155253@codesynthesis.com>

Hi Henning,

Henning Becker <henning.becker@apworks.de> writes:

> I'm trying to persist QPolygon from Qt as a value type. QPolygon
> inherits from QVector<QPoint> and no data will be lost, if it is
> handled just as a QVector<QPoint>.
> 
> I have defined QPoint as a composite value type:
> #pragma db value(QPoint) transient
> #pragma db member(QPoint::x_) virtual(int) get(x) set(setX)
> #pragma db member(QPoint::y_) virtual(int) get(y) set(setY)
> 
> But how can I make odb handle QPolygon as a QVector<QPoint>?

There are two ways: "quick and dirty" and "slow but clean" ;-).

The "quick and dirty" approach is to map QPolygon to a composite value
with a QVector<QPoint> member:

using QPolygonBase = QVector<QPoint>;
#pragma db value(QPolygon) transient
#pragma db member(QPolygon::points) virtual(QPolygonBase) access(this)

class Object
{
  ...
  
  QPolygon perimeter;
};

The major drawback of this approach is that the database table name for
perimeter will be called "object_perimeter_points" and not just
"object_perimeter".

The "slow but clean" approach is to define an odb:container_traits<QPolygon>
specialization, similar to the one defined from QVector<T> (in fact, you can
just derive from it). See the Qt profile for details on how this is done.

Boris

From henning.becker at apworks.de  Mon Mar  7 10:23:58 2016
From: henning.becker at apworks.de (Henning Becker)
Date: Mon Mar  7 10:24:11 2016
Subject: [odb-users] Persist container derived class as value type
In-Reply-To: <boris.20160307155253@codesynthesis.com>
References: <16565700.Bz92fURMOr@tegilbor.lan>
	<boris.20160307155253@codesynthesis.com>
Message-ID: <20263112.W2XLZaREFn@tegilbor.lan>

Am Montag, 7. M?rz 2016, 16:03:43 schrieben Sie:
> Hi Henning,
> 
> Henning Becker <henning.becker@apworks.de> writes:
> > I'm trying to persist QPolygon from Qt as a value type. QPolygon
> > inherits from QVector<QPoint> and no data will be lost, if it is
> > handled just as a QVector<QPoint>.
> > 
> > I have defined QPoint as a composite value type:
> > #pragma db value(QPoint) transient
> > #pragma db member(QPoint::x_) virtual(int) get(x) set(setX)
> > #pragma db member(QPoint::y_) virtual(int) get(y) set(setY)
> > 
> > But how can I make odb handle QPolygon as a QVector<QPoint>?
> 
> There are two ways: "quick and dirty" and "slow but clean" ;-).
> 
> The "quick and dirty" approach is to map QPolygon to a composite value
> with a QVector<QPoint> member:
> 
> using QPolygonBase = QVector<QPoint>;
> #pragma db value(QPolygon) transient
> #pragma db member(QPolygon::points) virtual(QPolygonBase) access(this)
> 
> class Object
> {
>   ...
> 
>   QPolygon perimeter;
> };
> 
> The major drawback of this approach is that the database table name for
> perimeter will be called "object_perimeter_points" and not just
> "object_perimeter".
> 
> The "slow but clean" approach is to define an odb:container_traits<QPolygon>
> specialization, similar to the one defined from QVector<T> (in fact, you
> can just derive from it). See the Qt profile for details on how this is
> done.
Hi Boris,
thanks for your answer. It seems to work perfectly. I've written a trait, 
which just derives from QVector<QPoint>.

Here is the code, maybe anybode else needs it:
namespace odb {
  template <>
  class access::container_traits<QPolygon> : public 
access::container_traits<QVector<QPoint>>
  {};
}

Cheers,
Henning
> 
> Boris

-- 
_______________________________________
 
Henning Becker

Development Engineer

AIRBUS APWORKS GmbH
Willy-Messerschmitt-Str. 1
82024 Taufkirchen - Germany 
T: +49 (0) 89 607 29771  
F: +49 (0) 89 607 28239  
M: +49 (0) 174 9818097  
henning.becker@apworks.de 

AIRBUS APWORKS GmbH
Registered Office: Ottobrunn
District Court of Munich: HRB 141734
Managing Director: Joachim Zettler
Internet: www.apworks.de
_______________________________________


From boris at codesynthesis.com  Tue Mar  8 10:24:23 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar  8 10:24:22 2016
Subject: [odb-users] Problem with object loading view
In-Reply-To: <c5588f07cb444127964b559b8bd315c8@QEX.qosmotec.com>
References: <5661afcc586d4a17baefa081971e1d70@QEX.qosmotec.com>
	<boris.20160212174131@codesynthesis.com>
	<c5588f07cb444127964b559b8bd315c8@QEX.qosmotec.com>
Message-ID: <boris.20160308170041@codesynthesis.com>

Hi Marcel,

I finally got to looking into this. Sorry for the delay and thanks for
the test case.

Marcel Nehring <mne@qosmotec.com> writes:

> * I manually load all instances of class Derived from the database.
>   Derived has a polymorphic base class.
> * Loading an instance of Derived triggers loading of a class Foo due to
>   object relationships.
> * Loading of a Foo triggers loading of a Bar, let's call it A.
> * Bars are collected in a BarCollection and they know of the collection
>   they are a member of, so loading a Bar triggers loading of a BarCollection.
> * Loading of a BarCollection triggers loading of all contained Bars,
>   including a Bar B.
> * When Bar B is fully loaded the post load callback fires.
> * Inside this callback I manually try to load a Derived, since loading of
>   the Derived object from the first step is not yet finished it is not
>   present in ODB's session cache.

Just for the record, I think people shouldn't be allowed to do this
king of things ;-).


> (If it were, it would work fine)

Actually, I believe it is another instance being loaded. If it is the same
instance (with the same object id), it will be in the cache (it is entered
first thing, before any statement locking, etc).


> As I said, I am not sure if this is the problem that you already mentioned
> in you last message.

Yes, this is slightly different. You are not loading the view twice
recursively. You are, however, loading the same (type of) object
recursively both via the normal object-loading route and via the
object loading view (OLV). And the OLVs don't expect this. That is,
they except this to be "top-level call" with respect to any object
that they are loading.

I think (theoretically) it is possible to make it work at the expense
of fairly significant extra complexity. Just to summarize, OLV loads
raw data (called object image) for all objects in a single go. So it
uses its custom image type that is essentially an amalgamation of all
the object image types. So in this part it doesn't rely on any
"standard" object loading mechanisms (image, statement, etc.) that
would require locking. However, if the object has containers or
sections, then the view uses the standard mechanisms to load this
part. And that's where locking is required.

Normally, if the lock fails (recursive loading and statements are
already in use), then a "delay load task" is queued and performed
later. This task loads both the object itself and all its containers
and sections. As a result, we cannot just reuse this task (we have
already loaded the object itself) and will have to come up with a
special one that will only load the containers/sections. This will
add quite a bit of hair, especially in the polymorphic case and I
am not very keen on going this route.

One fairly simple workaround, for your case at least, would be to
use a lazy pointer for the Foo relationship. The idea is to first
load all the derived objects (so they all end up in the session).
Then have another loop that loads all the relationships. What do
you think?

Boris

From patricek at ringcentral.com  Wed Mar  9 14:05:56 2016
From: patricek at ringcentral.com (Patrice Khawam)
Date: Thu Mar 10 04:53:44 2016
Subject: [odb-users] ODB 2.5
Message-ID: <PS1PR03MB1580859A3387966D2FB3CBCCD7B30@PS1PR03MB1580.apcprd03.prod.outlook.com>

Hi Boris,

What's new in ODB 2.5 and ETA?

Thanks!





From sexymimi64 at gmail.com  Thu Mar 10 08:22:47 2016
From: sexymimi64 at gmail.com (=?UTF-8?Q?Michael_Mart=C3=ADn_Moro?=)
Date: Thu Mar 10 08:23:13 2016
Subject: [odb-users] Options --output-dir and --include-prefix
Message-ID: <CAGj2=aVqe8h5LmhO-YESmV7PcFh4hsu_E6U2X1DtLW8d55yO6A@mail.gmail.com>

Greetings !

I'm trying to put my odb files in a folder separate to my database objects,
but I can't make it so.

I'm using --output-dir to generate the files in "lib/odb", and
include-prefix to specify that the models are in "app/models".

The odb compiler works with that, but it generates some faulty includes.
Since --output-dir is "lib/odb", then all the ixx files are generated in
"lib/odb".
Plus, the odb compiler will always generate the ixx files in the same
folder as the hxx/cxx files, am I wrong ?

Because the odb compiler uses the --include-prefix options for the ixx
files as well.
So I end up with includes of "app/models/mymodel-odb.ixx", which doesn't
exist. A include to "./mymodel-odb.hxx" would've worked fine though.

Am I doing this wrong ?

-- 
*Micha?l Mart?n Moro*
{ Epitech. Tek4 }
{ UCA Cad?z - Computer Engineering }
From boris at codesynthesis.com  Thu Mar 10 10:16:39 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Mar 10 10:16:36 2016
Subject: [odb-users] Options --output-dir and --include-prefix
In-Reply-To: <CAGj2=aVqe8h5LmhO-YESmV7PcFh4hsu_E6U2X1DtLW8d55yO6A@mail.gmail.com>
References: <CAGj2=aVqe8h5LmhO-YESmV7PcFh4hsu_E6U2X1DtLW8d55yO6A@mail.gmail.com>
Message-ID: <boris.20160310171318@codesynthesis.com>

Hi Michael,

Michael Mart?n Moro <sexymimi64@gmail.com> writes:

> I'm using --output-dir to generate the files in "lib/odb", and
> include-prefix to specify that the models are in "app/models".
> 
> The odb compiler works with that, but it generates some faulty includes.

The --include-prefix option is meant for a (fairly common) situation
where you want to include everything (i.e., the object model headers
and ODB-generated headers) with the same prefix, say #include <foo/...>.

If you want to include object model and ODB headers differently, then
you will need to use --include-regex to process them differently.

Boris

From boris at codesynthesis.com  Thu Mar 10 10:53:54 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Mar 10 10:53:51 2016
Subject: [odb-users] ODB 2.5
In-Reply-To: <PS1PR03MB1580859A3387966D2FB3CBCCD7B30@PS1PR03MB1580.apcprd03.prod.outlook.com>
References: <PS1PR03MB1580859A3387966D2FB3CBCCD7B30@PS1PR03MB1580.apcprd03.prod.outlook.com>
Message-ID: <boris.20160310174605@codesynthesis.com>

Hi Patrice,

Patrice Khawam <patricek@ringcentral.com> writes:

> What's new in ODB 2.5

You can view the current NEWS file (which lists the major new features and
changes) here:

http://scm.codesynthesis.com/?p=odb/odb.git;a=blob;f=NEWS


> and ETA?

Uh, that's a hard one. Ideally we would like to wait until the build2
toochain[1] is able to handle ODB so that we can distribute the release
as bpkg packages. So, in essence, it would be the transitional release
that will include support for both old (autotools/VC++ projects) and
new (build2) build systems. Also, the plan is to make 2.5.0 the last
release that supports C++98/03 (I can't wait ;-)).

So, my rough estimate is another 4-5 months.

Boris

From asnagni at yahoo.com  Sat Mar 12 14:39:03 2016
From: asnagni at yahoo.com (Alain-Serge Nagni)
Date: Sat Mar 12 14:39:12 2016
Subject: [odb-users] ODB  cmake c++11 issue
References: <525342268.371947.1457811543748.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <525342268.371947.1457811543748.JavaMail.yahoo@mail.yahoo.com>

Hello to all,? I'm new to ODB and I'm in the process of evaluating it. We develop on Linux and for our build system we do use CMake. I was able to have the basic examples (e.g.: hello) running by using Per Edin cmake build environ (https://github.com/BtbN/OdbCmake). That's good stuff. The problem that we are having now is that when we try to use C++11 / 14? features like shared_ptr the build fails with the following message:? ?std::shared_ptr? has not been declared
That is very strange because we added an intruction at the beging of the CMakeLists.txt file to inform the compile to use C++11/14 features. This is instruction we added to force the compile to switch to C++11/14: cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
It looks like despite that instruction to force compiler to use C++11/14, ODB compiler sames to be stuck with C++98/03

Do anybody faced this problem and would anyone have a solution? 


Thank you for your help,Jean-Louis
From asnagni at yahoo.com  Sat Mar 12 18:28:05 2016
From: asnagni at yahoo.com (Alain-Serge Nagni)
Date: Sat Mar 12 18:28:13 2016
Subject: [odb-users] ODB cmake c++11 issue
References: <1118780510.479099.1457825285802.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1118780510.479099.1457825285802.JavaMail.yahoo@mail.yahoo.com>

Hi guys,? I solved the proble:??? By looking in the UseODB.cmake I figureed out we need to add the option:? STANDARD c++14

By adding that option to the to the "odb_compile" function everything is working fine. So you should have something like this:


odb_compile(OdbCMake_SOURCES STANDARD c++14 FILES ${OdbCMake_ODB_HEADERS} DB? sqlite GENERATE_QUERY GENERATE_SESSION GENERATE_SCHEMA)



Thank you
From a.pasternak at mt-robot.com  Mon Mar 14 19:42:46 2016
From: a.pasternak at mt-robot.com (Andreas Pasternak MT-Robot AG)
Date: Mon Mar 14 19:42:22 2016
Subject: [odb-users] Enum encapsulation + getters / setters  + query
Message-ID: <20160315004246.EGroupware.Sxk_eK-tek9JPKJUqms8lZK@mail.mt-robot.com>

Hello all,

I reorganized a bigger code project into smaller libraries. Now I get  
the following linker error:

undefined reference to 'typeinfo for odb::boost::date_time::special_value'
undefined reference to 'vtable for odb::boost::date_time::special_value'

I link to odb aswell as to boost datetime. I have no clue where this  
error is comming from. Its happening in the last step when linking the  
executable.

Best regards, Andreas

From boris at codesynthesis.com  Wed Mar 16 11:47:18 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Mar 16 11:46:47 2016
Subject: [odb-users] Re: undefined odb::boost::date_time symbols
In-Reply-To: <20160315004246.EGroupware.Sxk_eK-tek9JPKJUqms8lZK@mail.mt-robot.com>
References: <20160315004246.EGroupware.Sxk_eK-tek9JPKJUqms8lZK@mail.mt-robot.com>
Message-ID: <boris.20160316174347@codesynthesis.com>

Hi Andreas,

In the future please don't send a new question by reply to an old thread.
Instead, start a new thread with proper subject. See posting guidelines
for details:

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


Andreas Pasternak MT-Robot AG <a.pasternak@mt-robot.com> writes:

> Now I get the following linker error:
> 
> undefined reference to 'typeinfo for odb::boost::date_time::special_value'
> undefined reference to 'vtable for odb::boost::date_time::special_value'

You need to link the libodb-boost library since you seem to be using the
Boost profile.

Boris

From dieter.govaerts at bricsys.com  Fri Mar 18 04:55:22 2016
From: dieter.govaerts at bricsys.com (dieter.govaerts@bricsys.com)
Date: Fri Mar 18 11:58:51 2016
Subject: [odb-users] weak_ptr relations
Message-ID: <1458291322.521710764@apps.rackspace.com>

Hi,

Concerning the initial example of "6.4 Lazy Pointers", it explains that when loading an employee object then the associated employer object and in turn all employer associated employees get loaded. I understand that. But the employer.employees_ vector uses std::weak_ptr, thus where are the actual employee objects kept, or are these indirectly loaded employees directly send into oblivion?

Regards,
Dieter Govaerts 


From dieter.govaerts at bricsys.com  Fri Mar 18 10:44:26 2016
From: dieter.govaerts at bricsys.com (dieter.govaerts@bricsys.com)
Date: Fri Mar 18 11:58:51 2016
Subject: [odb-users] Compile error in XXX-odb.cxx when exchanging
 std::weak_ptr for odb::lazy_weak_ptr
Message-ID: <1458312266.702730891@apps.rackspace.com>

Hi,

I'm experiencing following compile error on Visual Studio 2013 when I exchange a std::weak_ptr for a odb::lazy_weak_ptr:

D:\\Dev\\shared\\thirdparty\\libodb\\include\odb/traits.hxx(178) : error C2504: 'odb::access::object_traits_impl<T,id_sqlite>' : base class undefined
        with
        [
            T=const Employer
        ]
... [see build.txt in attachment for full listing]

The problem is resolved when I remove the 'const' from the template argument. I like to have it with the 'const' however. How can I resolve this?

Best regards,
Dieter Govaerts


(see attachment for the full sample)

// test.h

#define LAZY_PTR
#ifdef LAZY_PTR
//#define NO_CONST
#endif

class Employee;
typedef std::shared_ptr<Employee> EmployeePtr;
typedef std::shared_ptr<const Employee> ConstEmployeePtr;

class Employer;
typedef std::shared_ptr<Employer> EmployerPtr;
typedef std::shared_ptr<const Employer> ConstEmployerPtr;

#pragma db object transient session
class Employee
    : public std::enable_shared_from_this<Employee>
{
public:
    ...
private:
    #pragma db id auto
    #pragma db member(id) virtual(unsigned int) get(this.impl().m_id) set(const_cast< unsigned int & >(this.impl().m_id))
#ifdef LAZY_PTR
#ifdef NO_CONST
    typedef odb::lazy_weak_ptr< Employer > employer_type;
#else
    typedef odb::lazy_weak_ptr< const Employer > employer_type;
#endif
#else
    typedef std::weak_ptr< const Employer > employer_type;
#endif
    #pragma db inverse(employees)
    #pragma db member(employer) virtual(employer_type) access(this.impl().m_employer)
    #pragma db member(name) virtual(std::string) access(this.impl().m_name)

    friend class odb::access;

protected:
    class Impl;
    const Impl & impl() const;
    Impl & impl();

private:
    Impl * const impl_;
};


// test_impl.h

#include "test.h"

class Employee::Impl
{
public:
    Impl();
    Impl(const Impl &);
#ifdef NO_CONST
    Impl(EmployerPtr const&, std::string const&);
#else
    Impl(ConstEmployerPtr const&, std::string const&);
#endif

public:
    unsigned int const m_id;
#ifdef LAZY_PTR
#ifdef NO_CONST
    odb::lazy_weak_ptr< Employer > m_employer;
#else
    odb::lazy_weak_ptr< const Employer > m_employer;
#endif
#else
    std::weak_ptr< const Employer > m_employer;
#endif
    std::string m_name;
};
-------------- next part --------------
A non-text attachment was scrubbed...
Name: odb_test.zip
Type: application/x-zip-compressed
Size: 94674 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/odb-users/attachments/20160318/855d7c03/odb_test-0001.bin
From boris at codesynthesis.com  Fri Mar 18 12:06:33 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Mar 18 12:06:36 2016
Subject: [odb-users] weak_ptr relations
In-Reply-To: <1458291322.521710764@apps.rackspace.com>
References: <1458291322.521710764@apps.rackspace.com>
Message-ID: <boris.20160318180242@codesynthesis.com>

Hi Dieter,

dieter.govaerts@bricsys.com <dieter.govaerts@bricsys.com> writes:

> Concerning the initial example of "6.4 Lazy Pointers", it explains that when
> loading an employee object then the associated employer object and in turn
> all employer associated employees get loaded. I understand that. But the
> employer.employees_ vector uses std::weak_ptr, thus where are the actual
> employee objects kept, or are these indirectly loaded employees directly
> send into oblivion?

They are "kept" in the session. Also, ODB detects the situation where
you are loading an object into weak_ptr that nobody else points to and
throws the odb::session_required exception (it is discussed in Section
6.2, "Bidirectional Relationships").

Boris

From mne at qosmotec.com  Mon Mar 21 07:06:55 2016
From: mne at qosmotec.com (Marcel Nehring)
Date: Mon Mar 21 07:07:06 2016
Subject: AW: [odb-users] Problem with object loading view
In-Reply-To: <boris.20160308170041@codesynthesis.com>
References: <5661afcc586d4a17baefa081971e1d70@QEX.qosmotec.com>
	<boris.20160212174131@codesynthesis.com>
	<c5588f07cb444127964b559b8bd315c8@QEX.qosmotec.com>
	<boris.20160308170041@codesynthesis.com>
Message-ID: <405dea3692814cc9b480104a0323bf9b@QEX.qosmotec.com>

Hi Boris,

thanks for having a look.

> One fairly simple workaround, for your case at least, would be to use a lazy pointer for the Foo relationship. The idea is to first load all the derived objects (so they all end up in the session).
> Then have another loop that loads all the relationships. What do you think?

I don't think this is a feasible solution for me. The example was greatly simplified. In reality there are many occasions where I do not load the objects explicitly but they get loaded due to (complex) object relations. Manually brachiating through all links to manually load the lazy pointers would mean a lot of overhead in my code.

I will have to think about this problem and see if I can come up with another design in the first place. Thanks for your assistance.

Regards,
	Marcel

From boris at codesynthesis.com  Mon Mar 21 11:35:22 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Mar 21 11:35:23 2016
Subject: [odb-users] Compile error in XXX-odb.cxx when exchanging
	std::weak_ptr for odb::lazy_weak_ptr
In-Reply-To: <1458312266.702730891@apps.rackspace.com>
References: <1458312266.702730891@apps.rackspace.com>
Message-ID: <boris.20160321172910@codesynthesis.com>

Hi Dieter,

dieter.govaerts@bricsys.com <dieter.govaerts@bricsys.com> writes:

> The problem is resolved when I remove the 'const' from the template
> argument. I like to have it with the 'const' however. How can I resolve
> this?

Can you replace line 13 in libodb/odb/lazy-ptr-impl.txx:

return static_cast<DB&> (db).template load<T> (id);

With:

return static_cast<DB&> (db).template load<
  typename object_traits<T>::object_type> (id);

And let me know if it helps?

Boris

From odb at a-cunningham.com  Mon Mar 21 13:56:51 2016
From: odb at a-cunningham.com (Andrew Cunningham)
Date: Mon Mar 21 13:56:58 2016
Subject: [odb-users] Re:Problem with object loading view
Message-ID: <CAGTJuHhofYSPDgPCic41N27HsjyaoT75RrBPN=NeGrpPL6ytXQ@mail.gmail.com>

>
> > One fairly simple workaround, for your case at least, would be to use a
> lazy pointer for the Foo relationship. The idea is to first load all the
> derived objects (so they all end up in the session).
> > Then have another loop that loads all the relationships. What do you
> think?
>
> I don't think this is a feasible solution for me. The example was greatly
> simplified. In reality there are many occasions where I do not load the
> objects explicitly but they get loaded due to (complex) object relations.
> Manually brachiating through all links to manually load the lazy pointers
> would mean a lot of overhead in my code.
>


Marcel,
Another approach you can use is to derive/implement a new type of lazy_ptr
that automatically loads the object (if needed) when you use the operator
-> or operator * on the lazy_ptr. That way you do not have any explicit
"loads".Of course is that you can only load an object in a transaction so
one needs to be careful when using the operators to only force an object
load in a transaction. Personally I wish this was the default mode of
operation of lazy_ptrs.

You can also use "sections" effectively to manage loading "sections" of
objects. That way you do not need to "micro-manage" loading of objects,
just those that reside in a section.

Andrew
From dieter.govaerts at bricsys.com  Mon Mar 21 11:54:00 2016
From: dieter.govaerts at bricsys.com (dieter.govaerts@bricsys.com)
Date: Tue Mar 22 09:32:15 2016
Subject: =?utf-8?Q?Re=3A_=5Bodb-users=5D_Compile_error_in_XXX-odb.cxx_when_exchang?=
	=?utf-8?Q?ing_std=3A=3Aweak=5Fptr_for_odb=3A=3Alazy=5Fweak=5Fptr?=
In-Reply-To: <boris.20160321172910@codesynthesis.com>
References: <1458312266.702730891@apps.rackspace.com> 
	<boris.20160321172910@codesynthesis.com>
Message-ID: <1458575640.786119508@apps.rackspace.com>


Hello Boris,

>> The problem is resolved when I remove the 'const' from the template
>> argument. I like to have it with the 'const' however. How can I resolve
>> this?
> 
> Can you replace line 13 in libodb/odb/lazy-ptr-impl.txx:
> 
> return static_cast<DB&> (db).template load<T> (id);
> 
> With:
> 
> return static_cast<DB&> (db).template load<
>   typename object_traits<T>::object_type> (id);
> 
> And let me know if it helps?

That fixed it indeed. Thank you!

Dieter

PS Just for the public archives: it was line 31 in libodb/odb/lazy-ptr-impl.txx.


From boris at codesynthesis.com  Tue Mar 22 11:54:43 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar 22 11:54:42 2016
Subject: [odb-users] Problem with object loading view
In-Reply-To: <405dea3692814cc9b480104a0323bf9b@QEX.qosmotec.com>
References: <5661afcc586d4a17baefa081971e1d70@QEX.qosmotec.com>
	<boris.20160212174131@codesynthesis.com>
	<c5588f07cb444127964b559b8bd315c8@QEX.qosmotec.com>
	<boris.20160308170041@codesynthesis.com>
	<405dea3692814cc9b480104a0323bf9b@QEX.qosmotec.com>
Message-ID: <boris.20160322175215@codesynthesis.com>

Hi Marcel,

Marcel Nehring <mne@qosmotec.com> writes:

> I don't think this is a feasible solution for me. The example was greatly
> simplified. In reality there are many occasions where I do not load the
> objects explicitly but they get loaded due to (complex) object relations.

Perhaps doing it in (appropriate) callbacks would work? Otherwise, I think
simplifying this is the way forward.

Boris

From boris at codesynthesis.com  Tue Mar 22 11:57:30 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar 22 11:57:30 2016
Subject: [odb-users] Compile error in XXX-odb.cxx when exchanging
	std::weak_ptr for odb::lazy_weak_ptr
In-Reply-To: <1458575640.786119508@apps.rackspace.com>
References: <1458312266.702730891@apps.rackspace.com>
	<boris.20160321172910@codesynthesis.com>
	<1458575640.786119508@apps.rackspace.com>
Message-ID: <boris.20160322175644@codesynthesis.com>

Hi Dieter,

dieter.govaerts@bricsys.com <dieter.govaerts@bricsys.com> writes:

> That fixed it indeed.

Thanks for the confirmation, I've committed it for the next release.

Boris

From boris at codesynthesis.com  Tue Mar 22 12:01:14 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar 22 12:01:14 2016
Subject: [odb-users] Re:Problem with object loading view
In-Reply-To: <CAGTJuHhofYSPDgPCic41N27HsjyaoT75RrBPN=NeGrpPL6ytXQ@mail.gmail.com>
References: <CAGTJuHhofYSPDgPCic41N27HsjyaoT75RrBPN=NeGrpPL6ytXQ@mail.gmail.com>
Message-ID: <boris.20160322175900@codesynthesis.com>

Hi Andrew, Marcel,

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

> Another approach you can use is to derive/implement a new type of lazy_ptr
> that automatically loads the object (if needed) when you use the operator
> -> or operator * on the lazy_ptr.

Yes, not a bad option, if you are always in a transaction. Will take "I
don't understand when and in which order my objects are loaded" to a whole
new level ;-).

Boris

From odb at a-cunningham.com  Tue Mar 22 13:13:08 2016
From: odb at a-cunningham.com (Andrew Cunningham)
Date: Tue Mar 22 13:13:16 2016
Subject: [odb-users] Re:Problem with object loading view
In-Reply-To: <boris.20160322175900@codesynthesis.com>
References: <CAGTJuHhofYSPDgPCic41N27HsjyaoT75RrBPN=NeGrpPL6ytXQ@mail.gmail.com>
	<boris.20160322175900@codesynthesis.com>
Message-ID: <CAGTJuHikz_+vWbybtm=Bkr50sLfDR2eALV9k62VHsN74tadjpQ@mail.gmail.com>

Boris,

Every C++ OODB I am familiar with uses that "pattern" where an object is
loaded automatically by the use of the -> or (*) operators. For example,
Versant, Objectivity. I think what Marcel was saying was that having to
manually manage the load'ing of lazy_ptrs is fine for simple examples, but
for a complex C++ object model it just becomes too much of a burden. Using
-> to load means you really have no idea when the object is loaded, and
that's a good thing!

I could contribute my work, but I created a specialization of my own
intrusive reference counted shared pointer type - very specific to my use
case.

 Andrew

On Tue, Mar 22, 2016 at 9:01 AM, Boris Kolpackov <boris@codesynthesis.com>
wrote:

> Hi Andrew, Marcel,
>
> Andrew Cunningham <odb@a-cunningham.com> writes:
>
> > Another approach you can use is to derive/implement a new type of
> lazy_ptr
> > that automatically loads the object (if needed) when you use the operator
> > -> or operator * on the lazy_ptr.
>
> Yes, not a bad option, if you are always in a transaction. Will take "I
> don't understand when and in which order my objects are loaded" to a whole
> new level ;-).
>
> Boris
>
From asnagni at yahoo.com  Wed Mar 23 20:50:01 2016
From: asnagni at yahoo.com (Alain-SergeNagni)
Date: Wed Mar 23 20:50:14 2016
Subject: [odb-users] Making a static pointer transient doesn't work
Message-ID: <0BF0AA8D-48CE-4D77-A89D-B8B275BACBDA@yahoo.com>

Hi guys,
  I'm evaluating ODB and I'm trying to make a static pointer transient by using this ODB pragma tag in the class interface (the .hpp file):  
           #pragma db transient 

By doing so I have a compiler error:  db pragma 'transient' is not associated with a declaration 


Any idea of what I'm doing wrong? I scanned the document and could not find a section dealing with static data members ( object or pointer to object). Maybe I miss it? Thank you for helping or directing me to the right section of the document . 


Thank you,
Alain-Serge

Sent from my iPad
From boris at codesynthesis.com  Thu Mar 24 03:17:30 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Mar 24 03:17:28 2016
Subject: [odb-users] Making a static pointer transient doesn't work
In-Reply-To: <0BF0AA8D-48CE-4D77-A89D-B8B275BACBDA@yahoo.com>
References: <0BF0AA8D-48CE-4D77-A89D-B8B275BACBDA@yahoo.com>
Message-ID: <boris.20160324091550@codesynthesis.com>

Hi Alain-Serge,

Alain-SergeNagni <asnagni@yahoo.com> writes:

> I'm evaluating ODB and I'm trying to make a static pointer transient by
> using this ODB pragma tag in the class interface (the .hpp file):
>            #pragma db transient 

Static data member are not stored in the database so you shouldn't declare
them transient. I've updated the manual to clairfy this.

Boris

From boris at codesynthesis.com  Thu Mar 24 03:27:54 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Mar 24 03:27:53 2016
Subject: [odb-users] Re:Problem with object loading view
In-Reply-To: <CAGTJuHikz_+vWbybtm=Bkr50sLfDR2eALV9k62VHsN74tadjpQ@mail.gmail.com>
References: <CAGTJuHhofYSPDgPCic41N27HsjyaoT75RrBPN=NeGrpPL6ytXQ@mail.gmail.com>
	<boris.20160322175900@codesynthesis.com>
	<CAGTJuHikz_+vWbybtm=Bkr50sLfDR2eALV9k62VHsN74tadjpQ@mail.gmail.com>
Message-ID: <boris.20160324091738@codesynthesis.com>

Hi Andrew,

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

> Every C++ OODB I am familiar with uses that "pattern" where an object is
> loaded automatically by the use of the -> or (*) operators.

Maybe that's the reason why they never took off ;-)?


> I think what Marcel was saying was that having to manually manage the
> load'ing of lazy_ptrs is fine for simple examples, but for a complex
> C++ object model it just becomes too much of a burden. Using -> to
> load means you really have no idea when the object is loaded, and
> that's a good thing!

I would disagree, but then ODB is flexible enough to allow you to
implement this semantics if you so desire. We definitely cannot
make it the default since the loading can happen only within a
transaction.

To elaborate a bit more in why I disagree: A lot of people got burnt
by Hibernate for exactly this reason: to much magic happens behind
the scenes which is nice initialy, as in "I don't need to think
how/when things are loaded", but later you end up with surprises
like "Why on earth this simple call takes 10 minutes? Turns out it
loads 20,000 other objects, for some reason!".

Boris

From asnagni at yahoo.com  Thu Mar 24 07:18:44 2016
From: asnagni at yahoo.com (Alain-SergeNagni)
Date: Thu Mar 24 17:21:34 2016
Subject: [odb-users] Making a static pointer transient doesn't work
In-Reply-To: <boris.20160324091550@codesynthesis.com>
References: <0BF0AA8D-48CE-4D77-A89D-B8B275BACBDA@yahoo.com>
	<boris.20160324091550@codesynthesis.com>
Message-ID: <8E4060A7-1E28-4BD2-A392-FC83F4ADF7FF@yahoo.com>

Hi Boris,
   Thank you for the clarification and I will get the updated document.

Talk soon,
Alain-Serge

Sent from my iPad

> On Mar 24, 2016, at 3:17 AM, Boris Kolpackov <boris@codesynthesis.com> wrote:
> 
> Hi Alain-Serge,
> 
> Alain-SergeNagni <asnagni@yahoo.com> writes:
> 
>> I'm evaluating ODB and I'm trying to make a static pointer transient by
>> using this ODB pragma tag in the class interface (the .hpp file):
>>           #pragma db transient
> 
> Static data member are not stored in the database so you shouldn't declare
> them transient. I've updated the manual to clairfy this.
> 
> Boris

From andrew at a-cunningham.com  Thu Mar 24 12:21:43 2016
From: andrew at a-cunningham.com (Andrew Cunningham)
Date: Fri Mar 25 12:32:55 2016
Subject: [odb-users] Re:Object Loading
Message-ID: <CAGTJuHjpu8p0OwfxeyT+gDmCW-AgDcp72kZPCz6M3Jcjjtfa8Q@mail.gmail.com>

Hi Boris,
I'm not sure that operator-> caused the OODB movement to falter :).

But the point that I am trying to make is that when 'porting' existing C++
with a complex object graph of relationships code (to ODB), it is very,very
tedious to use lazy loading and have to track down every time an object is
referenced and check its load state.

So in an initial port, one will avoid shared_lazy_ptr, and be using
shared_ptr. Thus we will load 20,000 objects ( or in my case 200,000
objects) by referencing a root object.

My suggestion remains that it would be useful to a subset of users to
provide an additional type of lazy_ptr  that has the 'auto-load' behavior.
You might think it is trivial to write,but not everyone is an expert in
advanced C++ templates, and traits and so forth.  As long as it is not the
default, I don't see the 'harm'' in it , apart from it being additional
work for you to maintain and document.
From dieter.govaerts at bricsys.com  Thu Mar 24 16:18:48 2016
From: dieter.govaerts at bricsys.com (dieter.govaerts@bricsys.com)
Date: Fri Mar 25 12:32:55 2016
Subject: [odb-users] Virtual std::vector< odb::lazy_shared_ptr<X> > crashes
 odb compiler
Message-ID: <1458850728.65519348@apps.rackspace.com>


Hi,

I'm experiencing an odb internal compiler crash when declaring a virtual std::vector< odb::lazy_shared_ptr<X> > member. Exchanging the odb::lazy_shared_ptr with a std::shared_ptr (undefine LAZY_PTR_VECTOR) or making the vector non-virtual (define NON_VIRTUAL) avoids the crash. The following code illustrates the this (I've reduced the code to the bare minimum):

#ifndef TEST_2_H
#define TEST_2_H

#include <memory>

#include <odb/core.hxx>
#include <odb/lazy-ptr.hxx>

#define LAZY_PTR_VECTOR
#ifdef LAZY_PTR_VECTOR
//#define NON_VIRTUAL
#endif
#ifndef LAZY_PTR_VECTOR
//#define NO_PRE_DECL_CRASH
#endif

#ifndef NO_PRE_DECL_CRASH
class Employee;
typedef std::shared_ptr<Employee> EmployeePtr;
#endif

class Employer;
typedef std::shared_ptr<const Employer> ConstEmployerPtr;

#pragma db object session
struct Employee
{
    #pragma db id auto
    unsigned id_;

    ConstEmployerPtr employer_;
};

#ifdef LAZY_PTR_VECTOR
typedef std::vector< odb::lazy_shared_ptr<Employee> > Employees;
#else
typedef std::vector< std::shared_ptr<Employee> > Employees;
#endif
#pragma db value(Employees) value_not_null

#pragma db object session
struct Employer
{
    #pragma db id auto
    unsigned  id_;

    #pragma db inverse(employer_)
#ifdef NON_VIRTUAL
    Employees employees_;
#else
    #pragma db member(employees) virtual(Employees) access(this.impl().m_employees)
#endif
};

#endif //TEST_2_H

Another crash occurs when undefining LAZY_PTR_VECTOR and defining NO_PRE_DECL_CRASH. I'm not sure it is related to the other. This one is less of a problem to me, I just came across it when reducing the code.

Dieter


From asnagni at yahoo.com  Sun Mar 27 07:33:30 2016
From: asnagni at yahoo.com (Alain-SergeNagni)
Date: Sun Mar 27 07:33:41 2016
Subject: [odb-users] Inverse pragma statement issue (circular relationship)
Message-ID: <07A7B075-4FCF-4F60-AFE8-F60FBA040AAF@yahoo.com>

Hi guys,
   I have an issue when trying to use the inverse pragma statement. I read chapter 6.2.2, chapter 8.2, and chapter 14.4.14 and it looks that I cannot solve this issue. Some hep will be appreciated.

So I have 2 classes that have a circular relationship. Both classes are deriving from the same parent class. The classes are also define in separate header files to keep things cleaner.

When I try to use the inverse pragma I will have the following compiler error:
                                  error:  . ')'  expected at the end of db pragma inverse
 
I couldn't find any help in the document or at least the root cause of this compiler issue.


1) in the first class I have defined a data member like this:

namespace connection
{
      class CMyContact : public Framework::CBaseSerializable
      {
            .....
            ......
            std::shared_ptr<Framework::CBaseSerializable> m_pSerialiazableObjects;
      };
}

#ifdef ODB_COMPILER
     #include  "CMyContactMessage.hpp"
#endif





2) in the second class I have define a dats member like this:

namespace connection
{
      class CMyContactMessage :  public Framework::CBaseSerializable
      {
            .....
            ......
            #pragma db inverse (CMyContact::m_pSerialiazableObjects)
            std::weak_ptr<Framework::CBaseSerializable> m_pMyContact;
      };
}




If needed I can provide the code for more details I just wanted to avoid overloading  this email  ;-) . On a side note, It's also important to point out that trough our evaluation, it's the only real issue that we are facing everything else same to work nicely the way it's advertised. Nice job guys. You also have a great documentation.

Thank you for your help,
Alain-Serge


Sent from my iPad
From boris at codesynthesis.com  Mon Mar 28 10:48:26 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Mar 28 10:48:34 2016
Subject: [odb-users] Re:Object Loading
In-Reply-To: <CAGTJuHjpu8p0OwfxeyT+gDmCW-AgDcp72kZPCz6M3Jcjjtfa8Q@mail.gmail.com>
References: <CAGTJuHjpu8p0OwfxeyT+gDmCW-AgDcp72kZPCz6M3Jcjjtfa8Q@mail.gmail.com>
Message-ID: <boris.20160328164515@codesynthesis.com>

Hi Andrew,

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

> My suggestion remains that it would be useful to a subset of users to
> provide an additional type of lazy_ptr  that has the 'auto-load' behavior.
> You might think it is trivial to write,but not everyone is an expert in
> advanced C++ templates, and traits and so forth.  As long as it is not the
> default, I don't see the 'harm'' in it , apart from it being additional
> work for you to maintain and document.

Yes, I think this is a valid point. I've added a potential new feature
to our list. Perhaps this could be a bool template argument. If we do
this it will only be after we drop support for C++98 since the number
of lazy pointers we currently have is too much.

Boris

From boris at codesynthesis.com  Mon Mar 28 11:14:30 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Mar 28 11:14:22 2016
Subject: [odb-users] Inverse pragma statement issue (circular relationship)
In-Reply-To: <07A7B075-4FCF-4F60-AFE8-F60FBA040AAF@yahoo.com>
References: <07A7B075-4FCF-4F60-AFE8-F60FBA040AAF@yahoo.com>
Message-ID: <boris.20160328165419@codesynthesis.com>

Hi Alain-Serge,

Alain-SergeNagni <asnagni@yahoo.com> writes:

> error:  . ')'  expected at the end of db pragma inverse

This error looks very strange. So, yes, can you please send a small test
case (just the two headers and the command lines you use to compile them)
that reproduces this.

Thanks,
Boris

From asnagni at yahoo.com  Mon Mar 28 18:16:15 2016
From: asnagni at yahoo.com (Alain-Serge Nagni)
Date: Mon Mar 28 18:16:23 2016
Subject: [odb-users] Inverse pragma statement issue (circular relationship)
In-Reply-To: <boris.20160328165419@codesynthesis.com>
References: <boris.20160328165419@codesynthesis.com>
Message-ID: <1356459190.1413691.1459203375298.JavaMail.yahoo@mail.yahoo.com>

Hi Boris,?? Sure, I did attached the header files to this email (actually you have 4 files now because I did put the pragma in different files). For the build process, I'm using CMake, so this what I have:
1) For the first file: CMyContactMessages.hpp

odb -d sqlite --generate-query --generate-session --generate-schema --std c++14 --output-dir /home/asnagni/Projects/LinuxPlatform/systemApps/ConnexionBuild/ConnexionDb/source/odb_gen --hxx-suffix .hpp --ixx-suffix _inline.hpp --cxx-suffix .cpp --odb-file-suffix _odb -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/Common/Serializer/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/Common/Serializer/source/odb_gen -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/Common/Base/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Connexion/ConnexionDb/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/Common/MemoryPool/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/AbstractOs/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/SerializableMessages/SerializableTypes/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/units/include/scalar -I/usr/local/include ../include/CMyContact.hpp
1) For the second file: CMyContactMessages.hpp
odb -d sqlite --generate-query --generate-session --generate-schema --std c++14 --output-dir /home/asnagni/Projects/LinuxPlatform/systemApps/ConnexionBuild/ConnexionDb/source/odb_gen --hxx-suffix .hpp --ixx-suffix _inline.hpp --cxx-suffix .cpp --odb-file-suffix _odb -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/Common/Serializer/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/Common/Serializer/source/odb_gen -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/Common/Base/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Connexion/ConnexionDb/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/Common/MemoryPool/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/AbstractOs/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/SerializableMessages/SerializableTypes/include -I/home/asnagni/Projects/LinuxPlatform/systemApps/Framework/units/include/scalar -I/usr/local/include ../include/CMyContactMessages.hpp


Please let me know if you need any additional information.
Thank you,Alain-Serge 

    On Monday, March 28, 2016 11:14 AM, Boris Kolpackov <boris@codesynthesis.com> wrote:
 

 Hi Alain-Serge,

Alain-SergeNagni <asnagni@yahoo.com> writes:

> error:? . ')'? expected at the end of db pragma inverse

This error looks very strange. So, yes, can you please send a small test
case (just the two headers and the command lines you use to compile them)
that reproduces this.

Thanks,
Boris


  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMyContact.hpp
Type: text/x-c++hdr
Size: 5198 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/odb-users/attachments/20160328/4a5df976/CMyContact.hpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMyContactMessages.hpp
Type: text/x-c++hdr
Size: 4528 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/odb-users/attachments/20160328/4a5df976/CMyContactMessages.hpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMyContactMessagesPragmas.hpp
Type: text/x-c++hdr
Size: 592 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/odb-users/attachments/20160328/4a5df976/CMyContactMessagesPragmas.hpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMyContactPragmas.hpp
Type: text/x-c++hdr
Size: 499 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/odb-users/attachments/20160328/4a5df976/CMyContactPragmas.hpp
From yoav.weiss at intel.com  Tue Mar 29 09:22:32 2016
From: yoav.weiss at intel.com (Weiss, Yoav)
Date: Tue Mar 29 09:22:42 2016
Subject: [odb-users] Mapping PostGIS POLYGON type
Message-ID: <E650D64AEB646045AE83BF4F2E97B8483F3AAB63@HASMSX110.ger.corp.intel.com>

I would like to use the PostGIS type polygon in my code, so my header will look like:

  #pragma db type("GEOMETRY(POLYGON)")
  geos::geom::Polygon* m_p_geom;

Is there a best known method to achieve this? What will be the most efficient implementation (trying to avoid conversions from/to strings)?

Yoav



---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
From boris at codesynthesis.com  Tue Mar 29 11:21:36 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar 29 11:21:26 2016
Subject: [odb-users] Inverse pragma statement issue (circular relationship)
In-Reply-To: <1356459190.1413691.1459203375298.JavaMail.yahoo@mail.yahoo.com>
References: <boris.20160328165419@codesynthesis.com>
	<1356459190.1413691.1459203375298.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <boris.20160329171959@codesynthesis.com>

Hi Alain-Serge,

Can you reduce it to the minimal but complete (i.e., compilable) test
case? Headers that you sent include headers that I don't have.

Boris

From alexandre.pretyman at gmail.com  Tue Mar 29 11:36:35 2016
From: alexandre.pretyman at gmail.com (Alexandre Pretyman)
Date: Tue Mar 29 11:37:11 2016
Subject: [odb-users] Mapping PostGIS POLYGON type
In-Reply-To: <E650D64AEB646045AE83BF4F2E97B8483F3AAB63@HASMSX110.ger.corp.intel.com>
References: <E650D64AEB646045AE83BF4F2E97B8483F3AAB63@HASMSX110.ger.corp.intel.com>
Message-ID: <CAAXc0FWg+8miiHuV=EtUTb7D+dKT9sivmQMzK6GYMM-bnK=CCg@mail.gmail.com>

Hi Yoav,

If you are using GEOS, they will have Well Known Binary (WKB) conversion
functions, so you will avoid the string conversion.

My little experience in this subject is using boost geometry, which only
had Well Known Text (WKT) at the time.

But the work flow I've used with SpatiaLite is like this:

Create your member variable with the DB type of the geometry, in SpatiaLite
is just called GEOMETRY, in PostGIS, if I recall correctly, it's the same.

*using* linear_ring = boost::geometry::model::ring<coordinate, true, true>;


class X {

// ...

#pragma db type("GEOMETRY")

linear_ring my_ring


};


Then you will create traits for that type, for you "geos::geom::Polygon"
but here is "linear_ring", for the DB Type, my example is SQLite, but
obviously you will need to do it in PostgreSQL, which the namespace for it
is "pgsql" instead of the "sqlite" in the example below.

I used the WKT functions from Boost Geometry, you would use the WKB from
GEOS (WKBReader & WKBWriter):

#pragma once#include <limits>  // std::numeric_limits#include
<sstream>#include <cstring> // std::memcpy#include
<boost/geometry/io/wkt/write.hpp>#include
<boost/geometry/io/wkt/read.hpp>#include <odb/sqlite/traits.hxx>

namespace odb{  namespace sqlite  {    *using* linear_ring =
boost::geometry::model::ring<coordinate, true, true>;
    template <>    class value_traits<linear_ring, id_text>    {
public:      typedef linear_ring value_type;      typedef linear_ring
query_type;      typedef details::buffer image_type;      static void
    set_value (linear_ring& v,                 const details::buffer&
b,                 std::size_t n,                 bool is_null)      {
       if (is_null)          v = linear_ring ();        else        {
        std::string wkt(b.data (), n);          bg::read_wkt(wkt, v);
      }      }      static void      set_image (details::buffer& b,
             std::size_t& n,                 bool& is_null,
     const linear_ring& v)      {        is_null = false;
std::ostringstream os;        const std::string& s (os.str ());
n = s.size ();        if (n > b.capacity ())          b.capacity (n);
      std::memcpy (b.data (), s.c_str (), n);      }    };  }}


Then you'll have to include those traits when persisting/loading the
object.


It's best to have Boris validate those steps.


Good luck!



On 29 March 2016 at 09:22, Weiss, Yoav <yoav.weiss@intel.com> wrote:

> I would like to use the PostGIS type polygon in my code, so my header will
> look like:
>
>   #pragma db type("GEOMETRY(POLYGON)")
>   geos::geom::Polygon* m_p_geom;
>
> Is there a best known method to achieve this? What will be the most
> efficient implementation (trying to avoid conversions from/to strings)?
>
> Yoav
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>



-- 
Alexandre Pretyman
From odb at a-cunningham.com  Tue Mar 29 12:05:44 2016
From: odb at a-cunningham.com (Andrew Cunningham)
Date: Tue Mar 29 12:06:25 2016
Subject: [odb-users] Re: odb-users Digest, Vol 67, Issue 11
In-Reply-To: <201603211600.u2LG02HY014679@codesynthesis.com>
References: <201603211600.u2LG02HY014679@codesynthesis.com>
Message-ID: <CAGTJuHiSZ-cZQrYTwsGSrF68dvfwsafmzy7UWg+ibM-cK0ohXw@mail.gmail.com>

>
> Yes, I think this is a valid point. I've added a potential new feature to
> our list. Perhaps this could be a bool template argument. If we do this it
> will only be after we drop support for C++98 since the number of lazy
> pointers we currently have is too much.
>

Sounds great - I think you could definitely drop support for C++98 anytime
you like . That would be dropping support for  Visual Studio 2005/2008 and
some quite old GCC versions?
It would not be unreasonable on the Windows side to require Visual Studio
2013 as the base C++ version. We hung on to VS 2010 for far too long , and
just moved to VS 2013. But maybe others here can comment?
From asnagni at yahoo.com  Tue Mar 29 15:15:20 2016
From: asnagni at yahoo.com (Alain-Serge Nagni)
Date: Tue Mar 29 15:15:55 2016
Subject: [odb-users] Inverse pragma statement issue (circular relationship)
In-Reply-To: <boris.20160329171959@codesynthesis.com>
References: <boris.20160329171959@codesynthesis.com>
Message-ID: <158430437.2453566.1459278920212.JavaMail.yahoo@mail.yahoo.com>

Hi Boris,? Ok I go your point. Was not sure about what you wanted. If I have to send you theses files that will be lot of files to clean up and they are in separate libraries (Serializer, Memory pool, Dynamic object creation etc...). I spent this morning looking into this again and this is what I found out and it is pretty interesting. When I changed the data member type (please see below) in the class CMyContactMessages (CMyContactMessages.hpp) it does compile an it is running properly: 

1) Original statement (this doesn't work):??????????? #pragma db inverse (Connexion::CMyContact::m_pVectortOfPrivateMessages)
??????????? std::weak_ptr<NagniFramework::CBaseSerializable> m_pContact; ????????? 

2) Second statement (that works):????????? #pragma db inverse (m_pVectortOfPrivateMessages)
????????? std::weak_ptr<Connexion::CMyContact> m_pContact;? ??? 


It looks like to be able to use the inverse pragma we can not use the base class type with the std::weak_ptr. The polymorphism same to not work. 


After having this working with the second statement, I did try to move the pragma in the CMyContactMessagesPragmas.hpp and it didn't work. This is statment (It's working and running without any problem):?????? #pragma db member (Connexion::CMyContactMessages::m_pContact) inverse (m_pVectortOfPrivateMessages)


Does is make sense to you what I'm seeing.
Thank you,Alain-Serge

 

    On Tuesday, March 29, 2016 11:21 AM, Boris Kolpackov <boris@codesynthesis.com> wrote:
 

 Hi Alain-Serge,

Can you reduce it to the minimal but complete (i.e., compilable) test
case? Headers that you sent include headers that I don't have.

Boris


  
From asnagni at yahoo.com  Tue Mar 29 15:21:08 2016
From: asnagni at yahoo.com (Alain-Serge Nagni)
Date: Tue Mar 29 15:21:15 2016
Subject: [odb-users] Inverse pragma statement issue (circular relationship)
In-Reply-To: <158430437.2453566.1459278920212.JavaMail.yahoo@mail.yahoo.com>
References: <boris.20160329171959@codesynthesis.com>
	<158430437.2453566.1459278920212.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <201670422.2403108.1459279268944.JavaMail.yahoo@mail.yahoo.com>

Hi Boris,? I'm sorry for the noise :-) , I forgot to attached the base classes to my first reply. As you can see there is nothing special to them.

Thank you,Alain-Serge
 

    On Tuesday, March 29, 2016 3:15 PM, Alain-Serge Nagni <asnagni@yahoo.com> wrote:
 

 Hi Boris,? Ok I go your point. Was not sure about what you wanted. If I have to send you theses files that will be lot of files to clean up and they are in separate libraries (Serializer, Memory pool, Dynamic object creation etc...). I spent this morning looking into this again and this is what I found out and it is pretty interesting. When I changed the data member type (please see below) in the class CMyContactMessages (CMyContactMessages.hpp) it does compile an it is running properly: 

1) Original statement (this doesn't work):??????????? #pragma db inverse (Connexion::CMyContact::m_pVectortOfPrivateMessages)
??????????? std::weak_ptr<NagniFramework::CBaseSerializable> m_pContact; ????????? 

2) Second statement (that works):????????? #pragma db inverse (m_pVectortOfPrivateMessages)
????????? std::weak_ptr<Connexion::CMyContact> m_pContact;? ??? 


It looks like to be able to use the inverse pragma we can not use the base class type with the std::weak_ptr. The polymorphism same to not work. 


After having this working with the second statement, I did try to move the pragma in the CMyContactMessagesPragmas.hpp and it didn't work. This is statment (It's working and running without any problem):?????? #pragma db member (Connexion::CMyContactMessages::m_pContact) inverse (m_pVectortOfPrivateMessages)


Does is make sense to you what I'm seeing.
Thank you,Alain-Serge

 

    On Tuesday, March 29, 2016 11:21 AM, Boris Kolpackov <boris@codesynthesis.com> wrote:
 

 Hi Alain-Serge,

Can you reduce it to the minimal but complete (i.e., compilable) test
case? Headers that you sent include headers that I don't have.

Boris


   

  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CBaseSerializable.hpp
Type: text/x-c++hdr
Size: 2224 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/odb-users/attachments/20160329/14b178c8/CBaseSerializable.hpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CSerializableObject.hpp
Type: text/x-c++hdr
Size: 1689 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/odb-users/attachments/20160329/14b178c8/CSerializableObject.hpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CSerializableObject.cpp
Type: text/x-c++src
Size: 1147 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/odb-users/attachments/20160329/14b178c8/CSerializableObject.cpp
From yoav.weiss at intel.com  Wed Mar 30 08:16:14 2016
From: yoav.weiss at intel.com (Weiss, Yoav)
Date: Wed Mar 30 08:16:27 2016
Subject: [odb-users] Mapping PostGIS POLYGON type
In-Reply-To: <CAAXc0FWg+8miiHuV=EtUTb7D+dKT9sivmQMzK6GYMM-bnK=CCg@mail.gmail.com>
References: <E650D64AEB646045AE83BF4F2E97B8483F3AAB63@HASMSX110.ger.corp.intel.com>
	<CAAXc0FWg+8miiHuV=EtUTb7D+dKT9sivmQMzK6GYMM-bnK=CCg@mail.gmail.com>
Message-ID: <E650D64AEB646045AE83BF4F2E97B8483F3AB839@HASMSX110.ger.corp.intel.com>

Thanks Alex for your help.

However, I still have an error when running odb with ?s (generate schema). The Error I get is:
error: unknown PostgreSQL type 'GEOMETRY'

The definition I used is (which is the PostGIS syntax for a polygon):
  #pragma db type("GEOMETRY(POLYGON)")
  geos::geom::LinearRing m_geom;

Eventually, since I do want odb to generate the schema, I need the correct type and not a conversion from string.

Is that possible or should I create the schema myself?



From: Alexandre Pretyman [mailto:alexandre.pretyman@gmail.com]
Sent: Tuesday, March 29, 2016 18:37
To: Weiss, Yoav <yoav.weiss@intel.com>
Cc: odb-users@codesynthesis.com
Subject: Re: [odb-users] Mapping PostGIS POLYGON type

Hi Yoav,

If you are using GEOS, they will have Well Known Binary (WKB) conversion functions, so you will avoid the string conversion.

My little experience in this subject is using boost geometry, which only had Well Known Text (WKT) at the time.

But the work flow I've used with SpatiaLite is like this:

Create your member variable with the DB type of the geometry, in SpatiaLite is just called GEOMETRY, in PostGIS, if I recall correctly, it's the same.


using linear_ring = boost::geometry::model::ring<coordinate, true, true>;


class X {

// ...

#pragma db type("GEOMETRY")

linear_ring my_ring


};


Then you will create traits for that type, for you "geos::geom::Polygon" but here is "linear_ring", for the DB Type, my example is SQLite, but obviously you will need to do it in PostgreSQL, which the namespace for it is "pgsql" instead of the "sqlite" in the example below.

I used the WKT functions from Boost Geometry, you would use the WKB from GEOS (WKBReader & WKBWriter):


#pragma once



#include <limits>  // std::numeric_limits

#include <sstream>

#include <cstring> // std::memcpy



#include <boost/geometry/io/wkt/write.hpp>

#include <boost/geometry/io/wkt/read.hpp>



#include <odb/sqlite/traits.hxx>

namespace odb

{

  namespace sqlite

  {

    using linear_ring = boost::geometry::model::ring<coordinate, true, true>;


    template <>

    class value_traits<linear_ring, id_text>

    {

    public:

      typedef linear_ring value_type;

      typedef linear_ring query_type;

      typedef details::buffer image_type;



      static void

      set_value (linear_ring& v,

                 const details::buffer& b,

                 std::size_t n,

                 bool is_null)

      {

        if (is_null)

          v = linear_ring ();

        else

        {

          std::string wkt(b.data (), n);

          bg::read_wkt(wkt, v);

        }

      }



      static void

      set_image (details::buffer& b,

                 std::size_t& n,

                 bool& is_null,

                 const linear_ring& v)

      {

        is_null = false;

        std::ostringstream os;

        const std::string& s (os.str ());

        n = s.size ();



        if (n > b.capacity ())

          b.capacity (n);



        std::memcpy (b.data (), s.c_str (), n);

      }

    };

  }

}



Then you'll have to include those traits when persisting/loading the object.



It's best to have Boris validate those steps.



Good luck!



On 29 March 2016 at 09:22, Weiss, Yoav <yoav.weiss@intel.com<mailto:yoav.weiss@intel.com>> wrote:
I would like to use the PostGIS type polygon in my code, so my header will look like:

  #pragma db type("GEOMETRY(POLYGON)")
  geos::geom::Polygon* m_p_geom;

Is there a best known method to achieve this? What will be the most efficient implementation (trying to avoid conversions from/to strings)?

Yoav



---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



--
Alexandre Pretyman
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
From steve.chen at ringcentral.com  Wed Mar 30 02:00:12 2016
From: steve.chen at ringcentral.com (Steve Chen)
Date: Wed Mar 30 08:28:40 2016
Subject: [odb-users] Insert & Update data to db is very slow in iOS 8.1.1
Message-ID: <1482C937-FB61-4C5B-AFFE-55292E5FB230@ringcentral.com>

Hi there,

We are using the ODB 2.4 with sqlite in our application, everything is good, but we met a performance problem on iOS8.1.1 device. 

Supposedly, the insert & update for single row should be very quickly, should be less than 1ms. However, in iOS 8.1.1 device, the performance is very bad, it costs around 20ms for single update. 

Is it a known issue? Or any miss configuration? 

Very appreciated if you can provide any suggestion.

From boris at codesynthesis.com  Wed Mar 30 08:52:11 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Mar 30 08:52:01 2016
Subject: [odb-users] Mapping PostGIS POLYGON type
In-Reply-To: <E650D64AEB646045AE83BF4F2E97B8483F3AB839@HASMSX110.ger.corp.intel.com>
References: <E650D64AEB646045AE83BF4F2E97B8483F3AAB63@HASMSX110.ger.corp.intel.com>
	<CAAXc0FWg+8miiHuV=EtUTb7D+dKT9sivmQMzK6GYMM-bnK=CCg@mail.gmail.com>
	<E650D64AEB646045AE83BF4F2E97B8483F3AB839@HASMSX110.ger.corp.intel.com>
Message-ID: <boris.20160330144830@codesynthesis.com>

Hi Yoav,

Weiss, Yoav <yoav.weiss@intel.com> writes:

> error: unknown PostgreSQL type 'GEOMETRY'

The way to handle this in ODB is via the extended database type mapping
support:

http://www.codesynthesis.com/~boris/blog/2012/07/18/custom-database-to-cxx-type-mapping-in-odb/

See also Section 14.8, "Database Type Mapping Pragmas" in the manual as
well as the pgsql/custom test in the odb-tests package.

Boris

From boris at codesynthesis.com  Wed Mar 30 09:48:21 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Mar 30 09:48:16 2016
Subject: [odb-users] Virtual std::vector< odb::lazy_shared_ptr<X> >
	crashes odb compiler
In-Reply-To: <1458850728.65519348@apps.rackspace.com>
References: <1458850728.65519348@apps.rackspace.com>
Message-ID: <boris.20160330153910@codesynthesis.com>

Hi Dieter,

Thanks for the test case. This is a pretty hairy problem that has to do
with lazy template instantiation in C++. In essence, since your lazy_ptr
is not used anywhere else except as an element in a container in a
virtual data member, it doesn't get instantiated.

There is not much we can do to handle this automagically (instantiating
things on the fly is possible but would require incremental re-parsing of
the instantiated classes into the ODB's semantics graph). Though crashing
is also not right. So I've fixed it to issue proper diagnostics. Now for
your test case ODB prints:

test.h:51:16: error: container element type is not instantiated
test.h:51:16: info: use typedef/using to instantiate

As suggested in the diagnostics, the workaround is to force the (shallow)
instantiation with a typedef, for example:

typedef odb::lazy_shared_ptr<Employee> EmployeeLazyPtr;

Boris

From alexandre.pretyman at gmail.com  Wed Mar 30 09:48:05 2016
From: alexandre.pretyman at gmail.com (Alexandre Pretyman)
Date: Wed Mar 30 09:48:41 2016
Subject: [odb-users] Mapping PostGIS POLYGON type
In-Reply-To: <boris.20160330144830@codesynthesis.com>
References: <E650D64AEB646045AE83BF4F2E97B8483F3AAB63@HASMSX110.ger.corp.intel.com>
	<CAAXc0FWg+8miiHuV=EtUTb7D+dKT9sivmQMzK6GYMM-bnK=CCg@mail.gmail.com>
	<E650D64AEB646045AE83BF4F2E97B8483F3AB839@HASMSX110.ger.corp.intel.com>
	<boris.20160330144830@codesynthesis.com>
Message-ID: <CAAXc0FUV3hiNf=AuN_gEwiShMd3bNZtsqQCEo-91aeEmPs-4XA@mail.gmail.com>

I'm extremely sorry, it's been long since I've done this. The link from
Boris' blog has all info, but to complete the example of SpatiaLite, I did
put the following db pragma before mapping the the object:

#pragma db map type("GEOMETRY") as("TEXT") to("GeomFromText((?),
4326)") from("AsText((?))")


On 30 March 2016 at 08:52, Boris Kolpackov <boris@codesynthesis.com> wrote:

> Hi Yoav,
>
> Weiss, Yoav <yoav.weiss@intel.com> writes:
>
> > error: unknown PostgreSQL type 'GEOMETRY'
>
> The way to handle this in ODB is via the extended database type mapping
> support:
>
>
> http://www.codesynthesis.com/~boris/blog/2012/07/18/custom-database-to-cxx-type-mapping-in-odb/
>
> See also Section 14.8, "Database Type Mapping Pragmas" in the manual as
> well as the pgsql/custom test in the odb-tests package.
>
> Boris
>



-- 
Alexandre Pretyman
From boris at codesynthesis.com  Wed Mar 30 10:02:40 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Mar 30 10:02:29 2016
Subject: [odb-users] Inverse pragma statement issue (circular relationship)
In-Reply-To: <201670422.2403108.1459279268944.JavaMail.yahoo@mail.yahoo.com>
References: <boris.20160329171959@codesynthesis.com>
	<158430437.2453566.1459278920212.JavaMail.yahoo@mail.yahoo.com>
	<201670422.2403108.1459279268944.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <boris.20160330155752@codesynthesis.com>

Hi,

Alain-Serge Nagni <asnagni@yahoo.com> writes:

> I forgot to attached the base classes to my first reply.

There are still files included that I don't have (e.g., CSimpleMutex.hpp).
And that's exactly the reason I asked you to send a minimal test case that
reproduces the problem rather than to send the missing files!

Here is an example of an excellent test case:

http://codesynthesis.com/pipermail/odb-users/2016-March/003153.html

Can you come up with something like this?

Boris

From agroisman3 at bloomberg.net  Wed Mar 30 10:15:50 2016
From: agroisman3 at bloomberg.net (Alexandre Groisman (BLOOMBERG/ 731 LEX))
Date: Wed Mar 30 10:15:56 2016
Subject: [odb-users] ODB Reconnect logic
Message-ID: <56FBDF9601AF00140039050D_0_70049@p057>

Hi Boris,

Just wanted to confirm how it works - I found an old message exchange between
you and another developer in which you mention that you incorporated ping and
reconnect into connection pool. My question is - if I don't use connection
pool factory explicitly and rely on odb::database to manage connections for
me, would I still get that logic? Does it do ping/reconnect prior to every
transaction? 
From boris at codesynthesis.com  Wed Mar 30 10:38:11 2016
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Mar 30 10:38:05 2016
Subject: [odb-users] ODB Reconnect logic
In-Reply-To: <56FBDF9601AF00140039050D_0_70049@p057>
References: <56FBDF9601AF00140039050D_0_70049@p057>
Message-ID: <boris.20160330163201@codesynthesis.com>

Hi Alexandre,

Alexandre Groisman (BLOOMBERG/ 731 LEX) <agroisman3@bloomberg.net> writes:

> Just wanted to confirm how it works - I found an old message exchange between
> you and another developer in which you mention that you incorporated ping and
> reconnect into connection pool. My question is - if I don't use connection
> pool factory explicitly and rely on odb::database to manage connections for
> me, would I still get that logic? Does it do ping/reconnect prior to every
> transaction? 

If you don't specify the connection factory explicitly, then the connection
pool is used by default and, in case of MySQL, with connection ping enabled.

So, yes, provided you don't obtain the connection yourself and then re-use
it for multiple transaction, each transaction will ask the pool for a
connection which will be pinged before being returned.

Boris

From asnagni at yahoo.com  Wed Mar 30 11:52:47 2016
From: asnagni at yahoo.com (Alain-Serge Nagni)
Date: Wed Mar 30 11:53:09 2016
Subject: [odb-users] Inverse pragma statement issue (circular relationship)
In-Reply-To: <boris.20160330155752@codesynthesis.com>
References: <boris.20160330155752@codesynthesis.com>
Message-ID: <698061316.3045451.1459353167515.JavaMail.yahoo@mail.yahoo.com>

Hi Boris,? As explained in the previous emails, the problem is fixed. And it's working. The polymorphism doesn't work for the inverse pragma. So we just changed the data type and things are back on track.
?As stated in the previous emails and as you noticed we have lot of files and module/libraries involved, so cleaning up all these files to have it compile for you will take time. Since we have it working, we are all set. We send you these files to show you that there is nothing funky we did in terms of class definition. Anyway now it's working the way it is supposed to work.
? When I get a bit of time I will try your suggestion for the test case an update you on the results.?
What we really like about this library is that it doesn't force you to change your classes signature or code in a certain way and that is a big plus for us. Great job.


Thank you for the help and talk to you soon,Alain-Serge
 

    On Wednesday, March 30, 2016 10:02 AM, Boris Kolpackov <boris@codesynthesis.com> wrote:
 

 Hi,

Alain-Serge Nagni <asnagni@yahoo.com> writes:

> I forgot to attached the base classes to my first reply.

There are still files included that I don't have (e.g., CSimpleMutex.hpp).
And that's exactly the reason I asked you to send a minimal test case that
reproduces the problem rather than to send the missing files!

Here is an example of an excellent test case:

http://codesynthesis.com/pipermail/odb-users/2016-March/003153.html

Can you come up with something like this?

Boris