Package: redasher
RedasherThis tool manages Redash objects as files,
enabling version control and having development environments.The purpose of this tool is to serializeRedashobjects
(dashboards, queries, visualizations...)
into the filesystem so that they can be maintained using tools like Git.
You might use that to keep track of the changes with tools like git, or
you can even modify those objects with a text editor and update your instance.
By tracking a second Redash instance you can use this tool to syncronize objects among them.
This is useful, for example, to make and test changes in a development  environment
and eventually apply those changes into a production one.UsageLets start by defining our production server, by setting up the base url
and the API key of the user we will use to interact.redashersetupprodhttp://redash.mycompany.com:8012a2xcvvr23werwcdvhtsdfa23424dfA configuration file in~/.config/redash_gitstudio/config.yamlwill be created.Then lets download all the objects fromprodredashercheckoutprodThis will create the following directory structure in the current directory:maps/
maps/prod.yaml # mappings from local files to object ids in `prod` server
dashboards/<name>/metadata.yaml # dashboards metadata
dashboards/<name>/widgets/<name>.yaml # dashboard widgets
queries/<name>/query.sql # The query string file
queries/<name>/metadata.yaml # The rest of the metadata
queries/<name>/visualizations/<name>.yaml # query visualizatonsYou can put those files under the wing of a version control system like git,
and keep track of your object changes in redash
by running checkout and committing resulting files at any step.You can also modify the content of those files
and then upload them back to the server:redasheruploadproddashboard/my-dashboardAnother common workflow is working with an internal server
to develop without disturbing production users and
synchronize when you are done with the changes.For that you must define a new server:redashersetupdevhttp://localhost:8080sdfa23424dfa2xcvvr23werwcdvhtRedash datasource objects are considered readonly.
If you want to synchronize two servers, first you must
manually bind the datasource file object
checked out from the first server, to the
id of an equivalent datasource you created in the second server.redasherbinddevdatasource/my-database.yaml3Then you can upload the objects to create them.redasheruploaddevdashboard/my-dashboardFrom now on, succesive file uploads to the new server
will be updates on the same objects.Understanding maps/The directorymapscontains a file for each server.
Such files relate server object id's to file objects.
Such a relation is set the first time you checkout an object from a server,
or the first time you upload an object into a server and thus creating a new object.When you upload a file object to a server.
If the file object already has a bound id on the server,
the object is updated.
Otherwise a new object is created.Likewise, whenever you checkout an object from a server,
if the map exists, the content will be dump in the same file.
If not, a proper file name will be generated based on the slug
of the current object name.
If the name already exists a serial number is added.You can also set a server mapping by hand with thebindsubcommand
like in the previous example with the datasource.DesignDecision LogSluggified names are used as object file names since they are more easily spotted than a hashSluggified names are keept even if the name of the object changes laterNon composition relations are mapped with an attribute refering the object path names instead of ids.Numeric id's from server are instance dependantA common numeric serialization id would solve that but it would be harder to search and replaceComposition relations (dashboard -> widgets, query -> visualizations) are
mapped as directory hierarchy. This eases copying objects as a whole.Ids in each redash instance are different so "instance id" to "object file" maps should be tracked per instanceWhile production object mapping should be part of a shared repository,
private development servers might have sense for a single developer.
So, file-id maps should be in different files for each file so you can
decide which servers are shared in a repository.Permanent mapping from id and a file object should be stablished:The first time you download a given server object with no previous bound in that serverThe first time you upload a file object to a given server with no previous bound in that serverSuccessive uploads and downloads should keep that bindingUploading a file object to a server where it has a bound, should update the object instead of creating itDownloading an object from a server having already a bound to a file object, overwrites the same file objectData sources are mapped as well but not updated on upload, since they might point to different database configurations depending on the instance.Thus, before uploading objects refering to a datasource into a new instance,
it has to be created in the instance and bound using the bind command before uploading.Server configuration is not to be committed, and apikey should be kept private,
thus it has been separated from the server id map into a user configuration file.Users might be different in production and testing, a dashboard could
be created using a different user.
Thus, creation and modification users are not keptObject creation and modification dates are not to be kept, or do they? (they might be used to compare update times and detecting overwritten changes)Cascading uploadsUploading a dashboard uploads all its widgetsUploading a widget uploads its dashboard and its visualizationUploading a visualization uploads its queryUploading a query uploads its datasource, its visualizations and any param queryTODOPartial checkoutsAlerts and destinationsGroupsDetecting overwritting changes on uploadgit ops executed automatically