On 27 May 2013 22:26, Brian Ravnsgaard Riis <[email protected]> wrote:
> Hi,
>
> I've been experimenting with SOCI for a couple of days now, trying to use
> it to do ORM agains a SQLite3 backend. Found a weird issue that I really
> do not understand, and seems to make SOCI useless for ORM. I'm guessing I
> miss something obvious.
>
> Given:
>
> class Category
> {
>      public:
>          Category(std::string const & name) :
>              name_(name)
>          { }
>
>          std::string Name() const
>          { return name_; }
>
>          void Name(std::string const & name)
>          { name_ = name; }
>
>      private:
>          std::string name_;
> };
>
> I would expect type_conversion to be specialized as follows:
>
> namespace soci {
> template <> struct type_conversion<Category>
> {
>      typedef values base_type;
>
>      static void to_base(Category const & c,
>                          base_type & v,
>                          indicator & ind)
>      {
>          v.set("CategoryName", c.Name(),
>                c.Name().empty() ? i_null : i_ok);
>          ind = i_ok;
>      }
>
>      static void from_base(base_type const & v,
>                            indicator ind,
>                            Category & c)
>      {
>          if(ind == i_ok)
>              c.Name(v.get<std::string>("CategoryName"));
>      }
> };
>
> And called as:
>
> sql << "INSERT INTO Categories (CategoryName) VALUES(:CategoryName)",
>      soci::use(c_instance1);
>
> sql << "SELECT Categoryname FROM Categories", soci::into(c_instance2);
>
> However in from_base ind is always some random value, probably outside the
> indicator enum range and never yet i_ok. I tried making a local indicator
> variable and passing it to soci::into but the same thing happens. If I
> initialize it to i_ok before passing it, it works.

Brian,

Thanks for reporting this.

No, you are not missing anything, your use case looks fine.

It seems there is a bug in SOCI caused by uninitialised indicator members
of conversion_into_type and conversion_use_type specialisations.

I have opened issue:

https://github.com/SOCI/soci/issues/152

and I have proposed fix in this pull request

https://github.com/SOCI/soci/pull/153

It hasn't been merged, as it is to be decided if we want to
postpone release of this fix until SOCI 4.0.0.

Meanwhile, if you could check if this fix solves your problem,
that would be very helpful. You can grab it from my fork of the repo
and checkout bugfix/152-indicators branch:

git clone git://github.com/mloskot/soci.git
git checkout bugfix/152-indicators

then build SOCI and test your program with it.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users

Reply via email to