Hi Giuseppe On Thu, Jul 28, 2011 at 10:22 AM, Giuseppe Sucameli <[email protected]> wrote: > Hi devs, > I'm starting to work on the import layer feature as part of my GSoC. > > The aim would be to add to providers the capability to import a QGis layer > into databases. Creating a file is already managed by QgsVectorFileWriter, > but I would move that code within the OGR provider. > > This feature would allow users to copy a layer between different databases or > to save a layer loaded in canvas into dbs. > > I need your opinion about the way I should use to call the provider's import > method. > > There're at least 2 possible ways to add the import method: > 1. adding it as a static method and exporting it, > 2. adding it as a provider instance method. > > IMHO the second approach could be better as it could be easily used by > plugins too (just add the import method to QgsVectorDataProvider), instead > the first one needs to use QLibrary.
For now I would go with the first option since it is less invasive. The functionality could be used also by plugins: a simple method could be added to QgsProviderRegistry that would do the QLibrary magic. The problem with the second option is that we would need to create dummy provider instances that do not actually open any layer, they just make a connection. I know this happens already in WMS provider for data items, but I am not particularly happy about that because it creates a mess. For a real solution we would need another interface. Look at OGR library for an example: there is OGRDataSource interface that lists layers, opens layers or creates new ones. This is missing in QGIS. We need an abstract "data source" class that would encapsulate a connection to database, to a web service or to a file/directory. These data sources would be implemented by each data provider and they would also provide new layer and data items functionality. However such changes need more time to complete, that is why I would stay with the first option. I am wondering what other devs think.... Martin _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
