![]() ![]() Since the JSON in this file represents the Tabular Object Model (TOM), it turns out that there is a straight forward way to break the file down into smaller pieces: The TOM contains arrays of objects at almost all levels, such as the list of tables within a model, the list of measures within a table, the list of annotations within a measure, etc. What is Save to Folder?Īs mentioned above, the model metadata for a tabular model is traditionally stored in a single, monolithic JSON file, typically named Model.bim, which is not well suited for version control integration. Moreover, Tabular Editor can split up this metadata into several smaller files using its Save to Folder feature. Tabular Editor aims to simplify this process by providing an easy way to extract only the semantically meaningful metadata from the Tabular Object Model, regardless of whether that model is an Analysis Services tabular model or a Power BI dataset. This forces Power BI developers to use 3rd party tools or come up with elaborate scripts or processes for properly versioning their data models - especially, if they want to be able to merge parallel tracks of development within the same file. From the perspective of a version control system, a zip file is a binary file, and binary files cannot be diff'ed, compared and merged, the same way text files can. The best they can do is export their Power BI report as a Power BI Template (.pbit) file which is basically a zip file containing the report pages, the data model definitions and the query definitions. Power BI dataset developers have it much worse, since they do not even have access to a text-based file containing the model metadata. However, we still need to deal with a single, monolithic file (the Model.bim file) containing all of the "source code" that defines the model. When Tabular Editor was first created, there was no option to get rid of this information from the Model.bim file created by Visual Studio, but that has luckily changed in more recent versions. Indeed, a version control system gives a much more detailed view of the changes that were made, who made them, when and why, so there is no reason to include it as part of the files being versioned. Just like source code for traditional software development, we do not want this kind of information to "contaminate" our model metadata. In other words, if you were to remove all of the modification metadata from the file, you would still end up with a perfectly valid TOM JSON-file, that you could deploy to Analysis Services or publish to Power BI, without affecting the functionality and business logic of the model. This was problematic, because not only was the information redundant (since the file itself also has metadata that describes who the last person to edit it was, and when the last edit happened), but from a version control perspective, this metadata does not hold any semantic meaning. This information was simply stored as additional properties on the JSON objects throughout the file. When developing tabular models with earlier versions of Visual Studio, the Model.bim JSON file was augmented with information about who modified what and when. For this reason, most popular version control systems are optimized for these types of files, for purposes of change detection and (automatic) conflict resolution.įor tabular model development, the "source code" is our JSON-based TOM metadata. This type of change conflict resolution is very common in traditional software development, where all of the source code resides in a large number of small text files. ![]() ![]() The use of a text-based file format makes it possible to handle conflicting changes in a graceful way, by using various diff tools that are often included with the version control system. With the introduction of the JSON-based model metadata used by the Tabular Object Model (TOM), integrating model metadata in version control has certainly become easier. Parallel development has traditionally been difficult to implement on Analysis Services tabular models and Power BI datasets (in this article, we will call both types of models "tabular models" for brevity). Git repository accessible by all team members (on-premises or hosted in Azure DevOps, GitHub, etc.).Power BI Premium Capacity/Power BI Premium-per-user with XMLA read/write enabled.SQL Server 2016 (or newer) Analysis Services Tabular.The destination of your data model must be one of the following:.This article describes the principles of parallel model development (that is, the ability for multiple developers to work in parallel on the same data model) and the role of Tabular Editor in this regard. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |