You can translate the question and the replies:

What is the best way to compare my local database changes to the remote database before doing a "Check-In"?

Hi! I'm doing Denodo development on my local workstation: 1) Check out a remote database to a local database 2) Make some changes 3) Test those changes Everything is great, until I'd like to see what I changed BEFORE I run a check in. I've tried using export.bat -r c:/temp/ to export my local database to repo format and then use a file diff tool to compare the local repo format to what is in SVN. The problem is that the export.bat -r option doesn't create the repo format in the exact same way as the "Check-In" does... the local export.bat -r script builds the .dependencies files differently... so even though I didn't change the dependencies of any of my views they are showing up as "different". I know I can IGNORE dependencies files in my file diff tool... but I started to wonder: 1) Is this the best way to see what has changed? 2) Is there a bug in the way export.bat -r works? (Since it doesn't match the format of what actually gets checked in to the repository) Thank you~!
user
11-05-2015 15:55:39 -0400

3 Answers

Hi! You can tell which elements are new, have been modified or marked for deletion before the check-in from the VDP admin tool. To see this you can disable conflicts detection (Tools > Admin Tool Preferences > VCS > Enable conflict detection) and then check in the database. In the Chek-in dialog you will see a tree with all the new, modified and marked for deletion elements that will be included in the check-in. Is this enough information or do you need more detailed information about the changes? If you need more information, what do you want to see exactly? Is using the admin tool a valid option or do you prefer to use the command line scripts for this?
Denodo Team
12-05-2015 07:39:32 -0400
Hi! Thank you for your reply. I think that I was avoiding the VDPadmin tool was because in the past I've made changes to the VQL and the VDPAdmin tool would NOT mark the element as changed. Furthermore, when I would try to check in my VQL changes through the VDPAdmin tool I was unable to check in the changes because the VDPAdmin Tool would report that nothing changed. This failure to mark the elements have changed contributed to me not trusting the tool when it comes to changes. Another example: When I recently did a source refresh on my base view some new fields were found and after I finished the wizard my base view had some new fields. However, the VDPAdmin tool marked nearly ALL derived views as changed also, even though I didn't propagate the new fields in the Base View to any derived view. This also leads me to NOT trust the VDPAdmin tool when it comes to SVN integration. Finally, when the VDPAdmin tool does properly mark something as changed, I can't easily see what the change was until I do a check in. When I do a check in, I get the extra window that allows me to see what it is going to check in, and IF I've configured an external DIFF tool, then I can see what changed. If I haven't configured an external DIFF viewer, the built in one doesn't really highlight the changes... To add to this, for some reason check-ins and check-outs are taking a long time (sometimes 30 minutes). Finally, there is an option for conflict detection but it isn't really explained in the HTML documentation (the documentation when I click the help icons from within the tool). Instead I have to go find the full PDF and search for "enable conflict detection" to see what it does. I don't mean to complain, but I do mean to show that ALL of these things combined get in my way as a developer... I just want to see what changed before I check something in and the VDPAdmin tool seems to get in my way. This leads me to want to use a DIFFERENT tool than the VDPAdmin tool. For the reasons above, I (and the developers at my company) are inclined to use different tools to see what actually changed. If I export my database to the repo format, then I can use ANY file diff tool that has the color coding that I like. Furthermore, exporting to repo format and then using an external file diff tool is WAY faster than doing a check in and having to wait for the VDPAdmin tool. -=-=-=- I don't mean to complain, I am however trying to give you visibility into my thinking. The Denodo VQLServer is an AWESOME tool. The fact that I can pull data from different places and combine it is powerful. But when it comes to a team doing development on a shared virtual database the VDPAdmin tool with the VCS integration still has room for improvement. We are struggling with slow check-ins, the orange boxes showing up on derived views when a base view changes (even though we didn't change the derived view) and the orange boxes NOT showing up when we would change something in the VQL. We just installed the 2015 March 5.5 update, so that should fix the orange box not showing up issue... but we still aren't ecstatic to use the VDPAdmin tool when it comes to checking in/checking out code. For now it seems that the export.bat -r option allows us to avoid the vdpadmin tool when doing comparisons... but since it uses a different dependencies algorithm we'll have to ignore the .dependencies files. Thank you~!
user
12-05-2015 16:19:02 -0400
Hi, Thanks for your answer! Addressing the points raised in your message: 1) Regarding the issue with the Admin Tool not showing the information about changed/unchanged elements, the latest 5.5 update corrected some problems to that regard, so you can check again to see if your problems are solved. Take into account that, if you make changes through the VQL shell, you will need to select 'File > Refresh' in order for them to be visible from the Admin Tool. That could also explain some of the problems you are experiencing. If you are still experiencing any issue please open a support case with that. 2) Regarding the detection of differences, as you say, it is very easy to configure a third-party tool (like p4Merge or CodeCompare, for instance) to highlight differences. The section "VCS Settings of the Administration Tool" of the VDP Administration Guide provides instructions about this. Future updates of Denodo will also include an additional option before the check-in to see the differences between the VQL code that is going to be committed and the copy in the local repository (that is, the VQL code as it was the last time it was checked in or out from/to the VCS). 3) Regarding some check-in and check-out operations taking a long time, keep in mind that VCS operations involve exporting/importing metadata from/to Denodo to the local repository, and then performing the actual check in/out of the element and its dependencies to the VCS system. Therefore, these operations can take some time. That said, the next 5.5 update which will be released in June, will include significant VCS performance improvements (especially in check-out operations), and it will also include a 'progress indicator' for checkin and checkout operations, so you can see what is going on and what percentage of the job has been completed. 4) Regarding the conflict detection option, as you say, the option is described in the VDP Administration Guide (section "Check In / Commit Operations"). This information will also be added to the HTML online help.
Denodo Team
13-05-2015 13:31:16 -0400
You must sign in to add an answer. If you do not have an account, you can register here