tvin support for prepared statements about sqlpp11 HOT 17 CLOSED

On 2014-08-11 23:28, dirkvdb wrote:

When binding parameters for prepared statements: tvin cannot be used.
e.g:

preparedItemAdd.params.RefId = sqlpp::tvin(item.refId);

generates a compilation error

Oh, nice idea, had not thought of that. Will look into it.

Beware though: you probably should not use it with parameters in
combination with == or != or !

from sqlpp11.

OK, added tvin assignment operators

Cheers,

Roland

from sqlpp11.

Sounds great.

I tried the latest develop branch, but it causes a compilation error in this insert preparation:

auto preparedItemAdd = m_db->prepare(
        insert_into(objects).set(
            objects.ObjectId    = parameter(objects.ObjectId),
            objects.ParentId    = parameter(objects.ParentId),
            objects.RefId       = parameter(objects.RefId),
            objects.Name        = parameter(objects.Name),
            objects.Class       = parameter(objects.Class),
            objects.MetaData    = sqlpp::verbatim<sqlpp::integer>("last_insert_rowid()")
        )
    );

the error:

/Users/dirk/Projects/doozy/server/../modules/sqlpp11/include/sqlpp11/insert_value_list.h:90:13: error: 
      no matching constructor for initialization of 'insert_value_t<typename
      assignment_t<column_t<Objects, ObjectId>, parameter_t<text,
      column_t<Objects, ObjectId> > >::_lhs_t>'
  ..._values(insert_value_t<typename Assignments::_lhs_t>{assignments._rhs}...)
             ^                                           ~~~~~~~~~~~~~~~~~~

I tracked down the commit which causes the compilation error to:
Added support for default values and result fields for inserts

from sqlpp11.

Sorry about that. I'll look into it.

BTW: Why do you use a pointer of the connector? I am just curious, since
I am always using references.

Cheers,

Roland

from sqlpp11.

BTW: Why do you use a pointer of the connector? I am just curious, since
I am always using references.

I also prefer references :-)

Because the constructor of the sqlpp::sqlite3::connection requires the connection_config struct shared_ptr as an argument, which makes it hard to provide it in the initializer list since I cannot create the config structure in one statement, I could create a function for it I guess now that I think of it.

My constructor:

Database::Database(const string& dbFilepath)
: m_statements(new PreparedStatements())
{
    auto config = std::make_shared<sql::connection_config>();
    config->path_to_database = dbFilepath;
    config->flags = SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE;

#ifdef DEBUG_QUERIES
    config->debug = true;
#endif

    m_db.reset(new sql::connection(config));
    createInitialDatabase();
    prepareStatements();
}

I assume the the config is interpreted at construction time of the connection class.

from sqlpp11.

Thanks for reporting. Hmm. That is going to take a bit longer, I think.

Background:
The assignemts in the insert_into statement are currently broken up into
columns and values since that makes it easier to create

insert into tab C1, C2, C3 VALUES(V1, V2, V3);

But if you use the trivial_value_is_null tag in the column specfication,
you need information about the column when serializing the value. The
insert_value_t holds that information, but it is only good for values,
not for expressions like the verbatim you are using.

I have something in mind, but I am too tired to do that now :-)

If you go back the version that worked for you and cerry-pick the commit
for the tvin-assigment, you should be fine for the moment.

Best,

Roland

On 2014-08-12 22:23, dirkvdb wrote:

Sounds great.

I tried the latest develop branch, but it causes a compilation error
in this insert preparation:

auto preparedItemAdd = m_db->prepare(
insert_into(objects).set(
objects.ObjectId = parameter(objects.ObjectId),
objects.ParentId = parameter(objects.ParentId),
objects.RefId = parameter(objects.RefId),
objects.Name = parameter(objects.Name),
objects.Class = parameter(objects.Class),
objects.MetaData = sqlpp::verbatimsqlpp::integer("last_insert_rowid()")
)
);

the error:

|/Users/dirk/Projects/doozy/server/../modules/sqlpp11/include/sqlpp11/insert_value_list.h:90:13: error:
no matching constructor for initialization of 'insert_value_t<typename
assignment_t<column_t<Objects, ObjectId>, parameter_t<text,
column_t<Objects, ObjectId> > >::_lhs_t>'
..._values(insert_value_t{assignments._rhs}...)
^ ~~~~~~~~~~~~~~~~~~
|

I tracked down the commit which causes the compilation error to:
Added support for default values and result fields for inserts

—
Reply to this email directly or view it on GitHub
#10 (comment).

from sqlpp11.

Cherry picked and working.
Take your time ;-)

from sqlpp11.

On 2014-08-12 22:55, dirkvdb wrote:

BTW: Why do you use a pointer of the connector? I am just curious,
since
I am always using references.

I also prefer references :-)

Because the constructor of the sqlpp::sqlite3::connection requires the
connection_config struct shared_ptr as an argument, which makes it
hard to provide it in the initializer list since I cannot create the
config structure in one statement, I could create a function for it I
guess now that I think of it.

My constructor:

Database::Database(const string& dbFilepath)
: m_statements(new PreparedStatements())
{
auto config = std::make_sharedsql::connection_config();
config->path_to_database = dbFilepath;
config->flags = SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE;

#ifdef DEBUG_QUERIES
config->debug = true;
#endif

m_db.reset(new sql::connection(config));
createInitialDatabase();
prepareStatements();

}

I assume the the config is interpreted at construction time of the
connection class.

Actually, the config is stored almost never looked at again, except for
the debug. There is no real reason to use a shared pointer here, except
if you want to change the debug setting, but it might be better to have
a function for that...

Oh, btw you could use make_shared with arguments. All arguments are sent
to the constructor the type you make a shared_ptr for.

Anyway, I think, I'll change the shared_ptr to a reference to const.

Best,

Roland

from sqlpp11.

Oh, btw you could use make_shared with arguments. All arguments are sent
to the constructor the type you make a shared_ptr for.

Yes, but the connection_config does not have a constructor :-)

Anyway, I think, I'll change the shared_ptr to a reference to const.

Seems like a better choice indeed

from sqlpp11.

On 2014-08-12 23:20, dirkvdb wrote:

Oh, btw you could use make_shared with arguments. All arguments
are sent
to the constructor the type you make a shared_ptr for.

Yes, but the connection_config does not have a constructor :-)

You could use an initializer list. Although, maybe a function or lambda
is better here indeed, setting the members explicitly.

Anyway, I think, I'll change the shared_ptr to a reference to const.

Seems like a better choice indeed

Will do

from sqlpp11.

I tried the initializer list but couldn't get it to compile:

std::make_shared<sql::connection_config>({filename, int(SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE), "", false })

I also don't like the readability of out the blue boolean values like this.

from sqlpp11.

Can you try the current release?

You might stumble over new asserts in insert statements, because I reactivated a check that got dropped by accident a few weeks ago.

from sqlpp11.

The current release works fine for me.

Related to parameter binding:
I did notice that I cannot bind sqlpp::verbatim statements as parameter to prepared queries. I have worked my way around it but I think it would be a nice addition to support this if possible.

from sqlpp11.

On 2014-08-17 11:20, dirkvdb wrote:

The current release works fine for me.

Thanks for the quick answer :-)

Related to parameter binding:
I did notice that I cannot bind sqlpp::verbatim statements as
parameter to prepared queries. I have worked my way around it but I
think it would be a nice addition to support this if possible.

Can you make a new ticket for that?

from sqlpp11.

done

from sqlpp11.

Thanks!
I consider this ticket closed then.

BTW: The sqlite3-connector does not use the shared_ptr anymore in develop.

from sqlpp11.

Yes it can be closed

BTW: The sqlite3-connector does not use the shared_ptr anymore in develop.

Great!

from sqlpp11.