CDATA for Teiid Designer xmi files

[jpmat]

Dear all

For our project, we use Subversion or Git to store Teiid Designer projects (actually DV 6.2 projects). But when a change is done to SQL queries in a model, it's almost impossible to review the change because the SQL query is lost in middle of XMI file.

Would it be possible to surround all SQL queries in Teiid Designer xmi files by ![CDATA ? If I'm not wrong, this allows to keep the carriage return in SQL queries. And review / diff will be much easier to read.

Have a nice day

Jean-Pierre

[rareddy]

No, the XMI files are persistent versions of EMF models, it is not recommended to edit/change them manually. Anything not defined according to its persistent format you will end with an error. You should look into Dynamic VDB with DDL inside, there is good support for this with latest Teiid Designer, with this you can save text files into your SVN and import export as VDB in your Designer.

Ramesh..

[jpmat]

You always reply to use Dynamic VDB. I agree with you it's an elegant solution and I like it but in my company, it's not an option because:

• We 10 old VDB to maintain. We will not rewrite them all with Dynamic VDB.
• Most of us are not developer and cannot write directly CREATE instructions.

My idea is not to change the XMI file manually. It's more to change the persistence layer to always include formatted SQL of models in XML CDATA.

But it looks like you are not willing to spend development time on Teiid Designer now.

Jean-Pierre

[rareddy]

If you use latest Designer, you do not need to hand code the CREATE instructions, Designer does the export of the Dynamic VDB from the .VDB file's XMI files. Then it is question of maintaining them instead of the XMI files. You can use the Designer to import to build the model back from SVN.

Yes, we I always say that because that is direction of the Teiid we are taking, at a future date the .VDB files will be deprecated, I just do not want you to find this fact very late. Just simply saying we are not willing to put time time in Designer is a baseless claim. Take a look at all the Teiid Designer JIRAs and future Komodo work to see the direction of the project.

I will say that we are NOT going to be spending time on XMI files to make them easy to collaborate, we tried it, it did not work out as we expected. It is our goal to provide a environment that is, and that is where Dynamic VDB comes in.

Ramesh..

[werx.io]

the Dynamic VDB does seem to be a good candidate for development systems that need to version control changes. However, it does seem to create two sources, the database DML (or Liquibase or other change manager) and the dynamic VDB declaration. Also, we have hundreds of tables and views. This makes the initial investment rather "top heavy". 

[shawkins]

> This makes the initial investment rather "top heavy"

A vdb can just import its metadata at deploy time if the translator supports it - or you can plugin other methods or getting metadata.