You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
auto storage1 = make_storage(...);
auto storage2 = make_storage(...);
template<classT>
structAlias {
using type = T;
static std::string_view get() {
return"second"; // attached storage name
}
};
auto superStorage = storage1.attach<Alias>(storage2);
// superStorage is a storage with the same connection as storage1 has. superStorage keeps connection alive all its' life. Also it calls `ATTACH` command with `storage2` path and `second` name in ctor and `DETACH` in dtor (calling SQLite commands in dtor is a bad idea I know).
superStorage will know two schemas and will have the same API as regular storage has like select, get_all etc. To get all rows from the first storage one need to call regular query like
auto rows = superStorage.get_all<User>(); // SELECT * FROM users
To call the same type of objects from attached (second) storage one need to write the same code with alias:
auto rows = superStorage.get_all<Alias<User>>(); // SELECT * FROM second.users
Pros:
static type check works even for attached storage.
Cons:
connection sharing between storage1 and superStorage. It looks not bad but it may lead to some issues in future.
The second way
is more dynamic.
auto storage = make_storage(...);
template<classT>
structAlias : database_tag { // database_tag is important hereusing type = T;
static std::string_view get() {
return"second"; // attached storage name
}
};
storage.attach<Alias>("path_to_db.sqlite", make_storage(...)); // ATTACH path_to_db.sqlite AS secondauto rows = superStorage.get_all<User>(); // SELECT * FROM usersauto rows = superStorage.get_all<Alias<User>>(); // SELECT * FROM second.users
storage.detach<Alias>(); // DETACH second
Pros:
no static check. If type is passed as a class which inherits from database_tag then all static mapping checks are not performed.
no ctor and dtor logic which can fire an exception
Cons:
no connection sharing. All mapping stuff is stored in dynamic containers.
dynamic mapping check is not expected in sqlite_orm cause everything is done statically
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I am thinking about ATTACH feature implementation https://www.sqlitetutorial.net/sqlite-attach-database/. It looks easy to implement but I see two different ways of implementing it and I need some assistance.
The first way is totally static:
superStorage
will know two schemas and will have the same API as regular storage has likeselect
,get_all
etc. To get all rows from the first storage one need to call regular query likeTo call the same type of objects from attached (second) storage one need to write the same code with alias:
Pros:
Cons:
storage1
andsuperStorage
. It looks not bad but it may lead to some issues in future.The second way
is more dynamic.
Pros:
database_tag
then all static mapping checks are not performed.Cons:
sqlite_orm
cause everything is done staticallyBeta Was this translation helpful? Give feedback.
All reactions