[Qgis-developer] table join

Martin Dobias wonder.sk at gmail.com
Wed Dec 2 05:59:37 EST 2009


On Wed, Dec 2, 2009 at 12:51 AM, Jürgen E. <jef at norbit.de> wrote:
> Hi Martin,
>
> On Tue, 01. Dec 2009 at 23:39:24 +0100, Martin Dobias wrote:
>> As Marco has written, a way to achieve table joins will be to
>> transparently add further fields when iterating the vector layer. But
>> first of all we need some support for tables - basically it's the same
>> data type like vector layer but doesn't include a geometry, only
>> attributes. With ability to open and work with separate attribute
>> tables, we're half done (IMHO).
>
> Yes, that's also something I (shortly) discussed with Marco on the hackfest.
>
> A vector layer would have multiple data providers.  A primary with geometry
> and ids and secondaries for joined attributes along with an expression that
> connects an primary attribute with an secondary.
>
> The vector layer would report the attributes of all providers as fields.
>
> A nextFeature on the vector layer would trigger a nextFeature on the primary
> provider and for each secondary provider a setSubsetString with the expression
> from the primary provider and load the secondary attribute via select,
> nextFeature and add the secondary attributes to the feature.

Right, sounds like a way how to proceed.

Btw. are we talking only about left "outer" join or also inner joins?

> The question is how poor that will perform.

Naive table join implementation (i.e. for every feature find joined
table's row) will be probably usable only with very small layers and
tables. A good speed improvement (in exchange with some memory) would
be to keep the joined tables in memory. In future we probably end up
with a simple query scheduler that will recognize provider's
capabilities and indexes and choose an appropriate execution strategy.
Additionally we'll need an indexing structure (B-tree) for simple
providers (e.g. delimitedtext, gpx).

Martin


More information about the Qgis-developer mailing list