Red Gate forums :: View topic - Diffs when SSC changes order of rows in static table dump
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Source Control 3
SQL Source Control 3 forum

Diffs when SSC changes order of rows in static table dump

Search in SQL Source Control 3 forum
Post new topic   Reply to topic
Jump to:  
Author Message
bdw429s



Joined: 09 Aug 2012
Posts: 20
Location: Kansas

PostPosted: Thu Aug 09, 2012 6:30 pm    Post subject: Diffs when SSC changes order of rows in static table dump Reply with quote

I have briefly searched the forums and Google and couldn't find this question/suggestion anywhere.

When viewing text diffs on static data for peer reviews or when merging two branches together in source control, updates to records often appear as deletes and inserts because the row was placed in a different location in the dump file when the update was committed. This can make it difficult to determine what data actually changed in the table.

Is there a way to have SSC order the data in the static table dumps by the columns used for comparison (typically the primary key)? This would ensure that the "same" record stays on the same line in the file.

Yes, I'm aware that SQL Server doesn't inherently guarantee any order of data, and that there is no functional difference. The issue is that when you are using a text-based VCS where line numbers are meaningful and text diffs are required to view deltas and resolve merge conflicts, it's kind of important that the diff engine be able to expect a consistent representation of the data.

And yes, if the primary key (or whatever columns are being used for comparison) are changed, that would be acceptable to show as a new record sorted to a different place in the file.

Thanks!

~Brad
Back to top
View user's profile Send private message
maturmel



Joined: 25 Jan 2011
Posts: 24

PostPosted: Mon Aug 13, 2012 3:20 pm    Post subject: Reply with quote

+1

Aside the "committed" rows of a specific check-in, everything seems to be already ordered by PK in the text file dump. The new & modified rows appear either at the top or at the bottom of the file.

It does make branch merging a little nightmarish. Seems like keeping the order across all rows in the text dump would improve usability of branching merging with SQL Source Control.

This should be made a feature request that we can vote on.

Marc-Andre[/code]
Back to top
View user's profile Send private message
bdw429s



Joined: 09 Aug 2012
Posts: 20
Location: Kansas

PostPosted: Wed Aug 15, 2012 11:06 pm    Post subject: Reply with quote

Can anyone tell me where to submit this as a feature request?

Thanks!

~Brad
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1144
Location: My desk.

PostPosted: Thu Aug 16, 2012 9:30 am    Post subject: Reply with quote

Thanks for the posts here- as I understand it you want the format of our data files to be arranged differently (so they are in a simple comparison key ordering) to enable you to easily check them in a textual diff?

If so, you can request the feature on our Uservoice page: see here

Currently, we don't intend the files to be used in any way outside of our tools so the scenario you describe most likely hasn't been accounted for, but if lots of users also request the same feature it's something we can look into.
Back to top
View user's profile Send private message
bdw429s



Joined: 09 Aug 2012
Posts: 20
Location: Kansas

PostPosted: Thu Aug 16, 2012 5:36 pm    Post subject: Reply with quote

James, thanks for the reply. I will certainly submit an enhancement request.

For what it's worth, it was a Red Gate sales associate who actually suggested to me that branching and merging should be performed outside of SSC by a VCS tool. (Must have been over the phone as I can't find the E-mail) I would suggest that if Red Gate doesn't intend me to branch and merge with other VCS tools, that they build that functionality into SSC. Smile

In general though, I would caution against heading towards a proprietary solution that just so happens to use a few piece of another VCS system. I know you're trying to provide a turn-key solution but source control is built around the concept of human-readable text files which can be managed by any client. SSC should be embracing that or it will lose integration ability and nullify features if the underlying source control systems.

Thanks!

~Brad
Back to top
View user's profile Send private message
bdw429s



Joined: 09 Aug 2012
Posts: 20
Location: Kansas

PostPosted: Thu Aug 16, 2012 5:44 pm    Post subject: Reply with quote

Enhancement requested:

http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/3082371-diffs-when-ssc-changes-order-of-rows-in-static-tab

If you find this thread and agree, please click the link and vote Smile
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1144
Location: My desk.

PostPosted: Fri Aug 17, 2012 8:02 am    Post subject: Re: Reply with quote

Thanks for logging the request

bdw429s wrote:


For what it's worth, it was a Red Gate sales associate who actually suggested to me that branching and merging should be performed outside of SSC by a VCS tool. (Must have been over the phone as I can't find the E-mail) I would suggest that if Red Gate doesn't intend me to branch and merge with other VCS tools, that they build that functionality into SSC. Smile


Yes - this would most likely be because we don't implement any branching of our own - the original workflow would be to have a separate SQL DB linked to each Branch you created.

Once Migration scripts appeared it was found that these didn't work across-branches so when you merged changes back using whatever system you work with, the scripts created in the branch wouldn't run with the eventual merged set.
Back to top
View user's profile Send private message
bdw429s



Joined: 09 Aug 2012
Posts: 20
Location: Kansas

PostPosted: Fri Aug 17, 2012 4:33 pm    Post subject: Reply with quote

Interesting. Is that because the migration script is tied to the specific revision numbers that is goes between and when you merge and commit between branches, your changes are committed with new revision numbers?

I'm pretty certain some version systems store information about what revisions were merged and committed, but that would probably be unreliable for every source control system.

What are your plans for finding a way to tie the migration script to the appropriate revisions that will still work across a merge?
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1144
Location: My desk.

PostPosted: Mon Aug 20, 2012 8:37 pm    Post subject: Reply with quote

I'm afraid I'm not currently sure - I think it's still under investigation to a point. As you say, we don't want to necessarily use anything that's specific to a certain system as it makes it a lot harder to then change later on for other source-control tools.
Back to top
View user's profile Send private message
chunxing.shen@gmail.com



Joined: 14 Jul 2011
Posts: 1

PostPosted: Tue Aug 21, 2012 10:17 pm    Post subject: +1 Reply with quote

We are checking the data file into source control. Not ordering the data file consistently will make it very difficulty to control the changes. Please add this feature. Thanks!
Back to top
View user's profile Send private message
bdw429s



Joined: 09 Aug 2012
Posts: 20
Location: Kansas

PostPosted: Tue Aug 21, 2012 10:23 pm    Post subject: Reply with quote

If you want this feature, please go vote here:

http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/3082371-diffs-when-ssc-changes-order-of-rows-in-static-tab
Back to top
View user's profile Send private message
maturmel



Joined: 25 Jan 2011
Posts: 24

PostPosted: Thu Sep 06, 2012 2:14 pm    Post subject: Reply with quote

You got my vote on that. Smile

Thanks for posting.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group