[Qgis-developer] Table join branch

[Marco Hugentobler]

Hi John

Yes, an export adds all the joined fields to the new layer. So this provides a 
good workaround if the join performance is too slow. 

Regards,
Marco

Am Donnerstag, 22. Juli 2010, um 00.29:45 schrieb John C. Tull:
> Hi Marco,
> 
> This sounds like another great addition on your part. Is, or will there be,
> a means to export a joined layer to a vector format that creates an
> attribute table with both the original layer table and the joined table?
> In other words, will an export of a join result in a new layer complete
> with both attribute tables?
> 
> Thanks,
> John
> 
> On Jul 19, 2010, at 12:10 AM, Marco Hugentobler wrote:
> > Hi QGIS devs
> > 
> > There is now the table_join_branch (svn co
> > https://svn.osgeo.org/qgis/branches/table_join_branch) which contains an
> > initial table join prototype. Here is a short description how to use it:
> > - Load a vector layer
> > - Load a table layer. This can be done e.g. using 'Layer->Add Vector
> > Layer...' on a .dbf or .csv file
> > - Go to vector layer properties->join and click '+' to add a new join
> > - Select join field of table and join-to field of vector layer
> > - Now you should see the new fields in the attribute tab of the vector
> > layer properties, in the attribute table and in the info-tool window
> > 
> > Internally, QgsVectorLayer stores the join info (fields and join table
> > provider key) and remaps the field ids (first the provider ids, then the
> > joined field ids and last the added field ids). When querying the joined
> > field values, a subset string is set to the table provider to query a
> > feature with the value of the join field.
> > 
> > As you might expect, there are still a number of issues:
> > - Joined fields cannot be edited (should they?). So attribute table and
> > info- tool should disable those rows. QgsVectorLayer probably needs a
> > method to tell attribute table and info tool which rows are not
> > editable.
> > - Performance is an issue. The current implementation tries to improve
> > performance by automatically creating attribute indices in the ogr
> > provider (could be implemented in other providers too). Still there is a
> > siginificant performance penalty when doing classifications based on
> > joined attributes or attributes searches (info tool and opening
> > attribute table are usually fast, because not many features are queried
> > at once).
> > One possibility to enhance this could be to load tables into memory
> > providers and implementing attribute index capability there. Are there
> > other possibilities?
> > 
> > Looking forward to you feedback and suggestions. I'm sure there are a lot
> > of issues I didn't consider.
> > 
> > @Martin: in your gsoc blog, you write that you are refactoring the
> > editing buffer to a utility class. Do you think the join info and the id
> > remaping can be ported to the new design easily?
> > 
> > Regards,
> > Marco


-- 
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Webereistr. 66, CH-8134 Adliswil, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee