Is storage iterator return type supposed to differ with where usage?

[eclarkso]

[ My Obj is part of a storage that has other tables with FKs that point to it, if that is relevant ]

auto getObj(const std::vector<uint> & ids) {
  using namespace sqlite_orm;
  if(ids.size() == 0)
    return storage->iterate<Obj>();
  else
    return storage->iterate<Obj>(where(in(&Obj::id,ids)));
}

Results in this clang error (newlines added for clarity):

error: 'auto' in return type deduced as 
'sqlite_orm::internal::view_t<...giant type...>,sqlite_orm::internal::where_t<sqlite_orm::internal::in_t<unsigned int Obj::*, std::__1::vector<unsigned int>>>> 
here but deduced as 
'sqlite_orm::internal::view_t<...giant type...>' 
in earlier return statement
                        return storage->iterate<Obj> (where(in(&Obj::id,ids)));
                        ^

[ giant type are identical above]

Is this a bug? Similar code using get_all does compile, so it's at the very least surprising/inconvenient.

[fnc12]

it is not a bug cause storage.iterate function returns view_t<...giant type...> where 'giant type' depends on arguments you pass. The first case has no arguments, the second has. You'll meet the same logic if you write a code like this:

auto wh = where(in(&Obj::id, ids));
wh = where(is_equal(&Obj::id, 5));  // compilation error will happen on this line

You'll get compilation error cause where_t which is returned by where function has different template arguments -> it means that these two type returned by where(in(&Obj::id, ids)) and where(is_equal(&Obj::id, 5)) are different.
Why get_all returns the same type with where and without it? Cause this is a feature documented and guaranteed by sqlite_orm. But it is not guaranteed that storage_t::iterate will return the same types in the same cases. It just guarantees that some STL like object will be returned.

[eclarkso]

Does it need to be that way though - e.g.,

• have iterator_t<mappable_type, storage_t> as the template classes for that type instead of the entire view iterator<view_t>
  • changes its constructor to take in a storage reference instead of a view
• create view_iterator_t<mappable_type, storage_t
  • constructed with storage_t& and sqlite_stmt* constructor args/members
  • returns {nullptr, storage} for end() and {stmt, storage}
• add view_iterator_t<T,S> view_t::getIterator() that does the same thing as its current begin(), but instead of return {stmt, *this} does return view_iterator_t<T,S>(storage, stmt)
• in storage_t::iterate, construct the view (instead of returning it) and instead return ::getIterator()

Doing all that compiles - but I got a "database is locked" crash. I'm not sure if that implies "this could work, just needs tweaking" or "see, this is a bad idea". Maybe I just made a silly mistake in moving around storage references and/or sqlite statement pointers?

Anyway, you also might have larger reasons why some or all of the above is Bad as well, but just thought I'd throw this out as an idea after puzzling over this for a little while. If you're interested, I can attach a patch of what compiles (but doesn't work).

[fnc12]

probably we can replace iterator_t<V> to iterator<T> where V is a view type and T is a mapped type

[eclarkso]

That sounds awesome. Is there anything I can do to help?

[fnc12]

Implement it if you can. Or I can do it by myself in several days

[trueqbit]

Since PR #1452 and available with C++23, you can iterate over result sets in a type-agnostic manner.

auto getObj(const std::vector<uint> & ids) {
  using namespace sqlite_orm;
  if(ids.size() == 0)
    return storage->yield<Obj>();
  else
    return storage->yield<Obj>(where(in(&Obj::id,ids)));
}