For reference, I did some work around introducing uuids in the past, but never got it through https://github.com/apache/incubator-superset/pull/7829.
On Thu, Jun 18, 2020 at 9:16 AM Dennis Meyer <den...@jdeluxe.org> wrote: > Ok, I understand, this definitely makes good sense! > This would definitely be a great help for different envs. > > Dennis > > > On 18. Jun 2020, at 18:13, Andy Clapson <a...@slice.is> wrote: > > > > A big +1 on this one 👍. > > > > UUIDs would solve some definite deployment challenges on this one - > mainly importing a pre-built set of Dashboards into many different > environments. > > > > Andy > > > > On 2020-06-18 12:11, Maxime Beauchemin wrote: > >> I meant uuid in its pure form (just a universal unique identifier), not > a > >> fingerprint/hash of the object. > >> > >> Currently the importer has to keep track of the "export_object_id" to > try > >> to upsert properly if the same object is re-imported. It can have > collision > >> issue when multiple systems are involved and has other disadvantages. > >> > >> Max > >> > >> On Thu, Jun 18, 2020 at 6:35 AM Dennis Meyer <den...@jdeluxe.org> > wrote: > >> > >>> @Eric: > >>> Thanks for the feedback Eric. It’s good to know. We’ll keep it in the > >>> options list for now as this would also have some advantages :-) > >>> > >>> @Max: > >>> Removing the slice id and passing all parameters works, that’s really > >>> useful information. We might stick with this until slugs are available. > >>> Thanks very much! > >>> The charts can be static, but we need filtering on certain IDs. > Something > >>> like a product ID filter for example. But this seem to work ok with the > >>> approach by adding a simple filter :-) > >>> > >>> Rison would be awesome for debugging and developing for sure!Even > though > >>> UUIDs would solve our problem they can get a pain pretty quick if not > >>> architected very thoroughly. You have to use hashes in a consistent way > >>> (which data/column do you use? What happens with added columns on DDL > >>> updates etc) and dealing with those is non trivial when there’s no good > >>> transportable way in generating those across application and DBs. Slug > >>> seems to abstract the problem [at least the one we have] a lot better > and > >>> simpler at the same time. > >>> > >>> Dennis > >>> > >>>> On 18. Jun 2020, at 02:38, Erik Ritter <erik.t.rit...@gmail.com> > wrote: > >>>> > >>>> Hi Dennis, > >>>> > >>>> You mention that cloning the complete Superset database seems overkill > >>>> here, but for our use case, we've found that copying almost the entire > >>>> Superset db into our dev and staging environments solves these types > of > >>>> issues for us. To ensure the process doesn't take too long, we exclude > >>> the > >>>> `logs` and the `queries` tables from our DB dump, but everything else > we > >>>> copy straight from prod to dev and staging for testing purposes. > >>>> > >>>> I know this doesn't address a case where you build a chart in dev and > >>> want > >>>> to move it to prod, but that's not a pattern we've really seen or > needed > >>> in > >>>> our deployment. > >>>> > >>>> Hope this helps! > >>>> Erik > >>>> > >>>> On Wed, Jun 17, 2020 at 7:46 AM Maxime Beauchemin < > >>>> maximebeauche...@gmail.com> wrote: > >>>> > >>>>> Few thoughts: > >>>>> - did you try removing the id? this should work without the id since > >>> it's > >>>>> totally possible to have an explore session without a saved chart > >>>>> - we spoke in the past about introducing *uuids* for > >>> exportable/importable > >>>>> objects that would be consistent across superset instances > >>>>> - slugs for chart would help here, and should be easy to implement - > we > >>>>> need that regardless > >>>>> - side note: it'd be great to userison here for more readable URL > >>> encoding > >>>>> - more generally - should an embeddable snippet point to a chart or a > >>> state > >>>>> of an explore session? I think both use-cases make sense > >>>>> > >>>>> On Tue, Jun 16, 2020 at 12:39 PM Dennis Meyer <den...@jdeluxe.org> > >>> wrote: > >>>>>> Sorry for broken formatting. The URL contains an “slice_id”, see > edited > >>>>>> mail below for better readability. > >>>>>> > >>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> In the charts there’s an explicit embedding functionality > generating > >>>>>> Iframe code: > >>>>>>> <iframe > >>>>>>> width="600" > >>>>>>> height="400" > >>>>>>> seamless > >>>>>>> frameBorder="0" > >>>>>>> scrolling="no" > >>>>>> src="…slice_id=306…” > >>>>>> > >>>>>> > >>>>>>> </iframe> > >>>>>>> > >>>>>>> It seems like there’s an ID hardcoded (see above) - which is very > >>>>>> unfortunate when exporting and importing again and the embedding is > in > >>>>>> another application. In this case ids are different after import. > >>>>>>> I found a ticket about adding Slug to a chart, but it didn’t get > too > >>>>>> much attention. > >>>>>>> https://github.com/apache/incubator-superset/issues/6537 < > >>>>>> https://github.com/apache/incubator-superset/issues/6537> > >>>>>>> Is there currently a way to address this better if I wanted to use > >>>>>> embedding code in dev, staging and prod environments? > >>>>>>> Cloning the complete Superset database seems overkill for this. > Also > >>> it > >>>>>> won’t really work if you let production add charts by users and > create > >>>>> some > >>>>>> major charts in dev you want to move to prod after some thorough > >>> testing. > >>>>>>> I’m glad for any suggestion. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Dennis > >>>>>>> > >>>>>>> > >>>>>> > >>> > >
