mistercrunch commented on issue #27194: URL: https://github.com/apache/superset/issues/27194#issuecomment-2327518399
We do have a certain number of our core ORM models inherit a `uuid` through the `ImportExportMixin` https://github.com/apache/superset/blob/master/superset/models/helpers.py#L171-L174 Idea being that when exporting/importing object across Superset environments, we need to be able to recognize that objects are the same while potentially having different ids. Now we've talked about refactoring this many times over the years. Some related thoughts: - would be great to factor a `UuidModelMixin` out of `ImportExportMixin`, so it could could used in other (all!) models that are not necessarily exportable/importable - could be good to use the UUIDs as PKs and FKs too (instead of current auto-increment PKs), as it would greatly simlify export/import logic. Currently we have to do all sorts of lookup tables to figure stuff out. I think it has perf implications though as index become significantly larger - I could see someone arguing against that idea. - change the UI / API to be "UUID-native" and slowly deprecate exposing in of the internal auto-increment PKs as they expose a mild security threat, making it easy for user to guess urls and easily effectively scan through the data - seems you have a use case of forcing `uuids`, seems reasonable... assuming you'd need to be quite cautious about preserving referential integrity during update. Maybe export/re-import/deleting-orignals might make sense (?) In terms of moving forward. A first, non-controversial step in that direction that wouldn't require a SIP [AFAIC] would be to: - As mention, factor `UuidModelMixin` out of `ImportExportMixin` and into `superset/models/uuid.py`, make the second derive the former - Move/create utility methods that are uuid-specific under this new `superset/models/uuid.py` - spread across all models that could benefit from `uuid`, handle database migration to auto assign -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
