[odb-users] Object Loading Views with Containers / Alternatives?
Raphael Palefsky-Smith
me at raphieps.com
Sat Apr 13 15:13:44 EDT 2024
Hello! When it first starts up, my application loads a top-level object
with a deep hierarchy of related objects stored in odb::vectors.
For example, say I have an Employer that has many Employees, who each have
many Pets. These are all stored in odb::vectors, though I'm open to using
other schemes to make this work. Some pseudocode:
#pragma db object
class employer {
unsigned long id;
string address;
odb::vector<shared_ptr<employee>> employees; // non-lazy, need at
initial load
};
#pragma db object
class employee {
unsigned long id;
string name;
odb::vector<shared_ptr<pet>> pets; // non-lazy, need at initial load
};
#pragma db object
class pet {
unsigned long id;
string nickname;
};
For a given Employer ID, I'd like to load all the associated Employees and
all their Pets (along with the non-relational data members on those
Employer/Employees/Pets). It would be great to perform this load all in one
shot with a single JOIN'd SELECT; the naive db.load() executes a ton of
individual statements and is far too slow. It seems like Object Loading
Views are designed exactly for this purpose, but I can't seem to get them
working with containers.
My object loading view looks like this:
#pragma db view object(employer) object(employee) object(pet)
struct employer_with_employees_and_pets {
shared_ptr<employer> e;
};
When I query using this view, the stderr_tracer reports that individual
SELECTs are still being executed for each employee and pet instance. Is
there a way to modify the view so that it runs with a single SELECT?
If Object Loading Views are incompatible here, is there a workaround, even
if it involves hand-writing a bunch of SQL? Performance is more important
than source-code elegance in this specific case.
Thank you!
More information about the odb-users
mailing list