3party/sqlpp11
0
0
Fork 0
mirror of https://github.com/rbock/sqlpp11.git synced 2024-11-16 04:47:18 +08:00
Code Issues Projects Releases Wiki Activity
abf4bb8e9a
sqlpp11/tests/InterpretTest.cpp

165 lines
7.0 KiB
C++
Raw Normal View History

Started to switch from member serialize -> non-member interpret This will allow database connectors to specialize the interpretation of the expression tree and interpret queries in vendor specific ways where required.
2014-01-11 07:11:47 +08:00
/*
* Copyright (c) 2013, Roland Bock
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modification,
* are permitted provided that the following conditions are met:
*
* * Redistributions of source code must retain the above copyright notice,
* this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
* OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
* OF THE POSSIBILITY OF SUCH DAMAGE.
*/
Added python code generator as an example
2014-01-29 03:53:22 +08:00
#include "Sample.h"
Started to switch from member serialize -> non-member interpret This will allow database connectors to specialize the interpretation of the expression tree and interpret queries in vendor specific ways where required.
2014-01-11 07:11:47 +08:00
#include "MockDb.h"
Moved a bunch of things into namespace vendor This namespace is for things the developer will not get in touch with (normally) but the vendor might need to use for specialization of the interpreter. This separation is not fully completed yet, some changes will have to follow...
2014-01-18 22:50:16 +08:00
#include <sqlpp11/alias_provider.h>
interpret works for insert now Also added explicit .default_values() method
2014-01-14 06:05:48 +08:00
#include <sqlpp11/insert.h>
Added interpret support for remove()
2014-01-15 15:24:42 +08:00
#include <sqlpp11/select.h>
interpreter added for update()
2014-01-15 14:22:54 +08:00
#include <sqlpp11/update.h>
Added interpret support for remove()
2014-01-15 15:24:42 +08:00
#include <sqlpp11/remove.h>
Interpret works for parameters now Also, paramters inherit the operators they need
2014-01-14 04:00:20 +08:00
#include <sqlpp11/functions.h>
Started to switch from member serialize -> non-member interpret This will allow database connectors to specialize the interpretation of the expression tree and interpret queries in vendor specific ways where required.
2014-01-11 07:11:47 +08:00
#include <iostream>
DbMock db = {};
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
DbMock::_serializer_context_t printer(std::cerr);
Moved a bunch of things into namespace vendor This namespace is for things the developer will not get in touch with (normally) but the vendor might need to use for specialization of the interpreter. This separation is not fully completed yet, some changes will have to follow...
2014-01-18 22:50:16 +08:00
SQLPP_ALIAS_PROVIDER(kaesekuchen);
Started to switch from member serialize -> non-member interpret This will allow database connectors to specialize the interpretation of the expression tree and interpret queries in vendor specific ways where required.
2014-01-11 07:11:47 +08:00
int main()
{
Added python code generator as an example
2014-01-29 03:53:22 +08:00
test::TabFoo f;
test::TabBar t;
Started to switch from member serialize -> non-member interpret This will allow database connectors to specialize the interpretation of the expression tree and interpret queries in vendor specific ways where required.
2014-01-11 07:11:47 +08:00
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(insert_into(t).columns(t.beta, t.gamma), printer).flush();
Refactored insert to use policies Much cleaner now.
2014-02-09 04:06:23 +08:00
{
auto i = insert_into(t).columns(t.gamma, t.beta);
i.add_values(t.gamma = true, t.beta = "cheesecake");
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(i, printer).flush();
Refactored insert to use policies Much cleaner now.
2014-02-09 04:06:23 +08:00
i.add_values(t.gamma = false, t.beta = sqlpp::tvin("coffee"));
i.add_values(t.gamma = false, t.beta = sqlpp::tvin(std::string()));
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(i, printer).flush();
Refactored insert to use policies Much cleaner now.
2014-02-09 04:06:23 +08:00
i.add_values(t.gamma = sqlpp::default_value, t.beta = sqlpp::null);
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(i, printer).flush();
Refactored insert to use policies Much cleaner now.
2014-02-09 04:06:23 +08:00
}
Using assignments in add_values now This makes mistakes much less likely
2014-01-26 22:09:30 +08:00
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(t.alpha = sqlpp::null, printer).flush();
serialize(t.alpha = sqlpp::default_value, printer).flush();
serialize(t.alpha, printer).flush();
serialize(-t.alpha, printer).flush();
serialize(+t.alpha, printer).flush();
serialize(-(t.alpha + 7), printer).flush();
serialize(t.alpha = 0, printer).flush();
serialize(t.alpha = sqlpp::tvin(0), printer).flush();
serialize(t.alpha == 0, printer).flush();
serialize(t.alpha == sqlpp::tvin(0), printer).flush();
serialize(t.alpha != 0, printer).flush();
serialize(t.gamma != sqlpp::tvin(false), printer).flush();
serialize(t.alpha == 7, printer).flush();
serialize(t.beta + "kaesekuchen", printer).flush();
serialize(sqlpp::select(), printer).flush();
serialize(sqlpp::select().flags(sqlpp::distinct), printer).flush();
serialize(select(t.alpha, t.beta).flags(sqlpp::distinct), printer).flush();
serialize(select(t.alpha, t.beta), printer).flush();
serialize(select(t.alpha, t.beta).from(t), printer).flush();
serialize(select(t.alpha, t.beta).from(t).where(t.alpha == 3), printer).flush();
serialize(select(t.alpha, t.beta).from(t).where(t.alpha == 3).group_by(t.gamma), printer).flush();
serialize(select(t.alpha, t.beta).from(t).where(t.alpha == 3).group_by(t.gamma).having(t.beta.like("%kuchen")), printer).flush();
serialize(select(t.alpha, t.beta).from(t).where(t.alpha == 3).group_by(t.gamma).having(t.beta.like("%kuchen")).order_by(t.beta.asc()), printer).flush();
serialize(select(t.alpha, t.beta).from(t).where(t.alpha == 3).group_by(t.gamma).having(t.beta.like("%kuchen")).order_by(t.beta.asc()).limit(17).offset(3), printer).flush();
serialize(parameter(sqlpp::bigint(), t.alpha), printer).flush();
serialize(parameter(t.alpha), printer).flush();
serialize(t.alpha == parameter(t.alpha), printer).flush();
serialize(t.alpha == parameter(t.alpha) and (t.beta + "gimmick").like(parameter(t.beta)), printer).flush();
serialize(insert_into(t), printer).flush();
serialize(insert_into(f).default_values(), printer).flush();
serialize(insert_into(t).set(t.gamma = true), printer).flush();
//serialize(insert_into(t).set(t.gamma = sqlpp::tvin(false)), printer).flush(); cannot test this since gamma cannot be null and a static assert is thrown
serialize(update(t), printer).flush();
serialize(update(t).set(t.gamma = true), printer).flush();
serialize(update(t).set(t.gamma = true).where(t.beta.in("kaesekuchen", "cheesecake")), printer).flush();
serialize(remove_from(t), printer).flush();
serialize(remove_from(t).using_(t), printer).flush();
serialize(remove_from(t).where(t.alpha == sqlpp::tvin(0)), printer).flush();
serialize(remove_from(t).using_(t).where(t.alpha == sqlpp::tvin(0)), printer).flush();
Added interpret support for remove()
2014-01-15 15:24:42 +08:00
Added interpreters for a bunch of functions and table aliases
2014-01-16 02:42:14 +08:00
// functions
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(sqlpp::value(7), printer).flush();
serialize(sqlpp::verbatim<sqlpp::detail::integral>("irgendwas integrales"), printer).flush();
serialize(sqlpp::value_list(std::vector<int>({1,2,3,4,5,6,8})), printer).flush();
serialize(exists(select(t.alpha).from(t)), printer).flush();
serialize(any(select(t.alpha).from(t)), printer).flush();
serialize(some(select(t.alpha).from(t)), printer).flush();
serialize(count(t.alpha), printer).flush();
serialize(min(t.alpha), printer).flush();
serialize(max(t.alpha), printer).flush();
serialize(avg(t.alpha), printer).flush();
serialize(sum(t.alpha), printer).flush();
serialize(sqlpp::verbatim_table("whatever"), printer).flush();
Added interpreters for a bunch of functions and table aliases
2014-01-16 02:42:14 +08:00
Added missing interpreter specializations, especially for serializable
2014-01-17 16:56:35 +08:00
// alias
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(t.as(t.alpha), printer).flush();
serialize(t.as(t.alpha).beta, printer).flush();
Added interpreters for a bunch of functions and table aliases
2014-01-16 02:42:14 +08:00
Added missing interpreter specializations, especially for serializable
2014-01-17 16:56:35 +08:00
// select alias
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(select(t.alpha).from(t).where(t.beta > "kaesekuchen").as(t.gamma), printer).flush();
Added missing interpreter specializations, especially for serializable
2014-01-17 16:56:35 +08:00
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(t.alpha.is_null(), printer).flush();
Added interpreters to is_null, multi_column, alias and select pseudo table
2014-01-17 05:31:43 +08:00
Added missing interpreter specializations, especially for serializable
2014-01-17 16:56:35 +08:00
// join
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(t.inner_join(t.as(t.alpha)).on(t.beta == t.as(t.alpha).beta), printer).flush();
Added missing interpreter specializations, especially for serializable
2014-01-17 16:56:35 +08:00
// multi_column
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(multi_column(t.alpha, (t.beta + "cake").as(t.gamma)).as(t.alpha), printer).flush();
serialize(multi_column(all_of(t)).as(t), printer).flush();
serialize(all_of(t).as(t), printer).flush();
Added missing interpreter specializations, especially for serializable
2014-01-17 16:56:35 +08:00
// dynamic select
Fixed all_of use in select
2014-02-08 23:29:21 +08:00
{
auto s = dynamic_select(db).dynamic_flags().dynamic_columns();
s.add_column(t.beta);
s.add_column(t.gamma);
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(s, printer).flush();
Fixed all_of use in select
2014-02-08 23:29:21 +08:00
}
{
auto s = dynamic_select(db).dynamic_flags().dynamic_columns();
s.add_flag(sqlpp::distinct);
s.add_column(t.beta);
s.add_column(t.gamma);
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(s, printer).flush();
Fixed all_of use in select
2014-02-08 23:29:21 +08:00
}
{
auto s = dynamic_select(db).dynamic_flags(sqlpp::distinct).dynamic_columns(t.alpha);
s.add_flag(sqlpp::all);
s.add_column(t.beta);
s.add_column(t.gamma);
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(s, printer).flush();
Fixed all_of use in select
2014-02-08 23:29:21 +08:00
}
Added missing interpreter specializations, especially for serializable
2014-01-17 16:56:35 +08:00
Added optional DISTINCT flag to count
2014-01-22 06:42:27 +08:00
// distinct aggregate
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(count(sqlpp::distinct, t.alpha % 7), printer).flush();
serialize(avg(sqlpp::distinct, t.alpha - 7), printer).flush();
serialize(sum(sqlpp::distinct, t.alpha + 7), printer).flush();
Fixed a bunch of smaller migration errors
2014-02-09 05:24:05 +08:00
Added serializer to interpreter The serializer has partial specializations for all templates. It is a good basis if the connector/database requires strings close to the standard. The interpreter is unspecialized (and uses a static assert to say so). It is a good basis if the connector/database requires a different interpretation, e.g. re-writing the expression tree. The interpretable_t implements three methods for interpretation: serializing with the sqlpp::serializer_context, serializing with the database's serialization context and interpretation with the database's interpretation context.
2014-02-19 00:45:08 +08:00
serialize(select(all_of(t)).from(t).where(true), printer).flush();
serialize(select(all_of(t)).from(t).where(false), printer).flush();
Started to switch from member serialize -> non-member interpret This will allow database connectors to specialize the interpretation of the expression tree and interpret queries in vendor specific ways where required.
2014-01-11 07:11:47 +08:00
return 0;
}
Reference in New Issue Copy Permalink