795eba3da6
This is a very large change. I'll try to outline what's going on.
1. This adds the **EditDataService** which manages editing **Sessions**.
1. Each session has a **ResultSet** (from the QueryExecutionService) which has the rows of the table and basic metadata about the columns
2. Each session also has an **IEditTableMetadata** implementation which is derived from SMO metadata which provides more in-depth and trustworthy data about the table than SqlClient alone can.
3. Each session holds a list of **RowEditBase** abstract class implementations
1. **RowUpdate** - Update cells in a row (generates `UPDATE` statement)
2. **RowDelete** - Delete an entire row (generates `DELETE` statement)
3. **RowCreate** - Add a new row (generates `INSERT INTO` statement)
4. Row edits have a collection of **CellUpdates** that hold updates for individual cells (except for RowDelete)
1. Cell updates are generated from text
5. RowEditBase offers some baseline functionality
1. Generation of `WHERE` clauses (which can be parameterized)
2. Validation of whether a column can be updated
2. New API Actions
1. edit/initialize - Queries for the contents of a table/view, builds SMO metadata, sets up a session
2. edit/createRow - Adds a new RowCreate to the Session
3. edit/deleteRow - Adds a new RowDelete to the Session
4. edit/updateCell - Adds a CellUpdate to a RowCreate or RowUpdate in the Session
5. edit/revertRow - Removes a RowCreate, RowDelete, or RowUpdate from the Session
6. edit/script - Generates a script for the changes in the Session and stores to disk
7. edit/dispose - Removes a Session and releases the query
3. Smaller updates (unit test mock improvements, tweaks to query execution service)
**There are more updates planned -- this is just to get eyeballs on the main body of code**
* Initial stubs for edit data service
* Stubbing out update management code
* Adding rudimentary dispose request
* More stubbing out of update row code
* Adding complete edit command contracts, stubbing out request handlers
* Adding basic implementation of get script
* More in progress work to implement base of row edits
* More in progress work to implement base of row edits
* Adding string => object conversion logic and various cleanup
* Adding a formatter for using values in scripts
* Splitting IMessageSender into IEventSender and IRequestSender
* Adding inter-service method for executing queries
* Adding inter-service method for disposing of a query
* Changing edit contract to include the object to edit
* Fully fleshing out edit session initialization
* Generation of delete scripts is working
* Adding scripter for update statements
* Adding scripting functionality for INSERT statements
* Insert, Update, and Delete all working with SMO metadata
* Polishing for SqlScriptFormatter
* Unit tests and reworked byte[] conversion
* Replacing the awful and inflexible Dictionary<string, string>[][] with a much better test data set class
* Fixing syntax error in generated UPDATE statements
* Adding unit tests for RowCreate
* Adding tests for the row edit base class
* Adding row delete tests
* Adding RowUpdate tests, validation for number of key columns
* Adding tests for the unit class
* Adding get script tests for the session
* Service integration tests, except initialization tests
* Service integration tests, except initialization tests
* Adding messages to sr.strings
* Adding messages to sr.strings
* Fixing broken unit tests
* Adding factory pattern for SMO metadata provider
* Copyright and other comments
* Addressing first round of comments
* Refactoring EditDataService to have a single method for handling
session-dependent operations
* Refactoring Edit Data contracts to inherit from a Session and Row
operation params base class
* Copyright additions
* Small tweak to strings
* Updated unit tests to test the refactors
* More revisions as per pull request comments
Microsoft SQL Tools Service
The SQL Tools Service is an application that provides core functionality for various SQL Server tools. These features include the following:
- Connection management
- Language Service support using VS Code protocol
- Query execution and resultset management
SQL Tools Service API Documentation
Please see the SQL Tools Service API documentation at https://microsoft.github.io/sqltoolssdk/.
Contribution Guidelines
We welcome many kinds of community contributions to this project! Whether it's a feature implementation, bug fix, or a good idea, please create an issue so that we can discuss it. It is not necessary to create an issue before sending a pull request but it may speed up the process if we can discuss your idea before you start implementing it.
Because this project exposes a couple different public APIs, we must be very mindful of any potential breaking changes. Some contributions may not be accepted if they risk introducing breaking changes or if they don't match the goals of the project. The core maintainer team has the right of final approval over any contribution to this project. However, we are very happy to hear community feedback on any decision so that we can ensure we are solving the right problems in the right way.
Ways to Contribute
- File a bug or feature request as an issue
- Comment on existing issues to give your feedback on how they should be fixed/implemented
- Contribute a bug fix or feature implementation by submitting a pull request
- Contribute more unit tests for feature areas that lack good coverage
- Review the pull requests that others submit to ensure they follow [established guidelines] (#pull-request-guidelines)
Code Contribution Guidelines
Here's a high level list of guidelines to follow to ensure your code contribution is accepted:
- Follow established guidelines for coding style and design
- Follow established guidelines for commit hygiene
- Write unit tests to validate new features and bug fixes
- Ensure that the 'Release' build and unit tests pass locally
- Ensure that the AppVeyor build passes for your change
- Respond to all review feedback and final commit cleanup
Practice Good Commit Hygiene
First of all, make sure you are practicing good commit hygiene so that your commits provide a good history of the changes you are making. To be more specific:
-
Write good commit messages
Commit messages should be clearly written so that a person can look at the commit log and understand how and why a given change was made. Here is a great model commit message taken from a blog post by Tim Pope:
Capitalized, short (50 chars or less) summary More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, followed by a single space, with blank lines in between, but conventions vary here - Use a hanging indentA change that fixes a known bug with an issue filed should use the proper syntax so that the issue is automatically closed once your change is merged. Here's an example of what such a commit message should look like:
Fix #3: Catch NullReferenceException from DoThing This change adds a try/catch block to catch a NullReferenceException that gets thrown by DoThing [...] -
Squash your commits
If you are introducing a new feature but have implemented it over multiple commits, please squash those commits into a single commit that contains all the changes in one place. This especially applies to any "oops" commits where a file is forgotten or a typo is being fixed. Following this approach makes it a lot easier to pull those changes to other branches or roll back the change if necessary.
-
Keep individual commits for larger changes
You can certainly maintain individual commits for different phases of a big change. For example, if you want to reorganize some files before adding new functionality, have your first commit contain all of the file move changes and then the following commit can have all of the feature additions. We highly recommend this approach so that larger commits don't turn into a jumbled mess.
Add Unit Tests for New Code
If you're adding a new feature to the project, please make sure to include adequate xUnit tests with your change. In this project, we have chosen write out unit tests in a way that uses the actual PowerShell environment rather than extensive interface mocking. This allows us to be sure that our features will work in practice.
We do both component-level and scenario-level testing depending on what code is being tested. We don't expect contributors to test every possible edge case. Testing mainline scenarios and the most common failure scenarios is often good enough.
We are very happy to accept unit test contributions for any feature areas that are more error-prone than others. Also, if you find that a feature fails for you in a specific case, please feel free to file an issue that includes a unit test which reproduces the problem. This will allow us to quickly implement a fix that resolves the problem.
Build 'Release' Before Submitting
Before you send out your pull request, make sure that you have run a Release configuration build of the project and that all new and existing tests are passing. The Release configuration build ensures that all public API interfaces have been documented correctly otherwise it throws an error. We have turned on this check so that our project will always have good generated documentation.
Follow the Pull Request Process
-
Create your pull request
Use the typical process to send a pull request from your fork of the project. In your pull request message, please give a high-level summary of the changes that you have made so that reviewers understand the intent of the changes. You should receive initial comments within a day or two, but please feel free to ping if things are taking longer than expected.
-
The build and unit tests must run green
Run all unit tests and code coverage tests to ensure all tests are passing and code coverage numbers and not negatively impacted by your change.
-
Respond to code review feedback
If the reviewers ask you to make changes, make them as a new commit to your branch and push them so that they are made available for a final review pass. Do not rebase the fixes just yet so that the commit hash changes don't upset GitHub's pull request UI.
-
If necessary, do a final rebase
Once your final changes have been accepted, we may ask you to do a final rebase to have your commits so that they follow our commit guidelines. If specific guidance is given, please follow it when rebasing your commits. Once you do your final push we will merge your changes!