rhunwicks commented on issue #3302: Create a PandasDatasource
URL: 
https://github.com/apache/incubator-superset/issues/3302#issuecomment-329281110
 
 
   @xrmx  it's true that if someone developed a model that had a dependency on 
a core Superset model, and then that model changed significantly, then the 
extension might stop working. But that would be the case whether or not the 
dependent model was in the core `superset/migrations/versions` directory or 
not. The impression I have from @mistercrunch comments above was that if we can 
write a `PandasConnector` it would be non-core anyway. And so given that 
objective it makes sense to try and keep the extension as loosely coupled as 
possible.
   
   Alembic, and thus Flask-Migrate, is quite capable of dealing with a branched 
migration tree, so changes can be made to the main models in the main tree 
without affecting the extension migrations provided that either they are not 
dependent on any upstream models or the upstream models don't change in a 
breaking way. For example, our models have a foreign key to `ab_user` but as 
long as changes to that model don't alter the primary key I don't think it will 
make any difference.
   
   If someone wrote an extension that did stop working as a result of change to 
an upstream model then they would need to update their component to account for 
the changes in order to continue working with the most recent version of 
Superset. This is a normal workflow for an add on component for an open source 
project.
   
   On balance, I think that it is preferable to have an 
`ADDITIONAL_VERSION_LOCATIONS` config parameter that would allow me to (attempt 
to) develop a `PandasConnector` that is minimally invasive to core Superset. I 
think that smaller the impact it has on core Superset the better chance it has 
of being successful. I think that the same logic might apply to other potential 
extensions - as I described at the start of this Issue there have been many 
requests for additional connectors, and making it easier for me and others to 
develop them without needing changes to core Superset or maintain a fork would 
likely increase the availability of such connectors.
   
   However, my main objective is to write a connector that can work with core 
Superset on an ongoing basis. So if the core team decide that Connectors should 
live in a contrib directory and keep their migrations in the main 
`superset/migrations/versions` directory then I'll happily comply.
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to