[odb-users] How to make a "lazy" QList?

Rene Jensen rene at catatonic.dk
Wed Nov 7 09:33:46 EST 2012


> Put (1) inside (2). In you suggestion it would mean having an
> > odb::qt::QList as the manager which internally manages a traditional
> > QList. For purposes of reading, the user would be able to gain access
> > to the stored QList.
>
> Yes, that is the idea. I think we can support what I would call "const
> inheritance" from QList by providing an implicit conversion operator
> to const QList&. This way odb::QList would behave as if it was derived
> from QList's const interface.
>

<snip>


> > As long as the user can A) control which underlying collection type is
> > used,
>
> I think this will just complicate things since in each case we would want
> to mimic the original container's interface as closely as possible. Why
> not just have odb::QList which is based on QList, std::vector which is
> based on std::vector, etc? This way ODB versions are just drop-in
> replacements for Qt/standard containers.
>


I'm not sure I can figure out exactly what you mean by "odb::QList which is
based on QList". Nevertheless I think we agree.
If I declare an odb::QList, I can gain const access to a real QList
If I declare an odb::std::vector, I can gain const access to a real
std::vector

What else could I possibly want :-)

Well, you *could* of course alleviate the need for that section solution we
discussed. If ODB could figure out that "managed" collections should NOT be
automatically loaded, then 99% of the superfluous database fetching could
be eliminated:

struct Shipment
{
    ...
    #pragma db managed // Not really needed, I know
    odb::QList<Parcel*> m_parcels;
}

QSharedPointer<Shipment> S= ...

S.m_parcels.load_all() // NOW we load all foreign keys. In fact also all
parcels from the parcel table

// Cast to get a QList...
checkAllParcels (  (const QList<Parcel*>)  S.m_parcels);
S.m_parcels[0].weight = 20



Best regards,
Rene Jensen


More information about the odb-users mailing list