Merge common code bases for TdsParserStateObject.cs #1520

panoskj · 2022-02-21T22:38:10Z

Related to #1261 and prerequisite for working on #593 without hindering the merge process.

This PR is a work in progress right now, but I would like some feedback while working on it.

Though it should be mergeable as it is too.

My questions for now:

Do the commits look good so far?
The netfx version uses ConstrainedRegions. Should they be removed or preserved?

dnfadmin · 2022-02-21T22:38:23Z

All CLA requirements met.

Wraith2 · 2022-02-23T10:17:58Z

The changes themselves look fine.
Constrained regions should be preserved, everything should be preserved including CAS so that the Microsoft version of this library is as close as possible to the System version.

There are a lot of other open PR's to merge other files in the solution and they're just sitting waiting to be reviewed and merged. The longer it's left the more change is likely to happen between you opening it and it being reviewed and merged meaning you have to keep rebasing. The rate of change in this repo isn't due to lack of will to make the changes it's all down to lack of time from the owners.

Wraith2 · 2022-03-02T17:54:59Z

I think you might want to change the shared version of the file to TdsParserStateObject.Common.cs because visual studio doesn't like having two files with the same name in a single tree level and it breaks the ability for it to track the currently editing file.

@DavoudEshtehari any chance of this getting bumped to the top of the list? it's needed for string perf issues.

DavoudEshtehari · 2022-03-02T22:30:17Z

The netfx version uses ConstrainedRegions. Should they be removed or preserved?
I agree with Wraith2.
Generally speaking, we strive to keep a PR, single-purpose, to avoid mixing up changes as much as possible.

any chance of this getting bumped to the top of the list? it's needed for string perf issues.
@Wraith2 thanks for the comment. 😊 We'll back to this after the next preview release.

…Object # Conflicts: # src/Microsoft.Data.SqlClient/netcore/src/Microsoft.Data.SqlClient.csproj # src/Microsoft.Data.SqlClient/netfx/src/Microsoft.Data.SqlClient.csproj

DavoudEshtehari

LGTM
Please, consider the following improvements:

Removing the unnecessary using statements.
Making the PacketData & StateSnapshot private and sealed.

src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs

src/Microsoft.Data.SqlClient/netfx/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs

…net#1060 from netcore to common file).

…ectives).

panoskj · 2022-03-18T17:33:02Z

I pushed two more commits, merging more methods.

Regarding the second commit, @Wraith2 and @DavoudEshtehari do you think using #if directives is a good idea in these cases?

There are many methods that differ by only a few lines. Some common cases are:

Exceptions that are handled in different ways (e.g. here and here).
Logging with SqlClientEventSource.Log.TryAdvancedTraceEvent is different.
Constrained Regions and Reliability Sections that we discussed previously.

In some cases it may be better to use a partial method, e.g. a wrapper for this method.

Also note netcore version didn't have the TdsParser.Is2005OrNewer property, but netfx did. Does this mean netcore version doesn't support SQL server 2005 while netfx does? I added the property in the second commit, but the same result could be achieved using an #if directive here.

Let me know how to proceed.

Wraith2 · 2022-03-18T18:05:45Z

Regarding the second commit, @Wraith2 and @DavoudEshtehari do you think using #if directives is a good idea in these cases?

In general. No. That doesn't mean there aren't situations where they aren't the right thing to do but in general if there is behavioural difference it should either be abstracted away or dealt with by having a separate version.

Also note netcore version didn't have the TdsParser.Is2005OrNewer property, but netfx did. Does this mean netcore version doesn't support SQL server 2005 while netfx does?

I've asked the same question in the past. It isn't actively supported but it also isn't something that should be removed as dead.

When we reached this point in the process of merging the codebases my idea was to move all the things which are identical to common and then have a PR per one or two functions at a time to make the reviews easier. As you've seen the time needed to review and merge these PR's outweighs the speed at which we can produce them. We need to make the process of reviewing as simple as possible which means the simplest PR's.

panoskj · 2022-03-18T18:26:36Z

In general. No. That doesn't mean there aren't situations where they aren't the right thing to do but in general if there is behavioural difference it should either be abstracted away or dealt with by having a separate version.

So, what do you think about the specific cases of the last commit? Most of the methods in this file have such "conflicts", so having a separate version doesn't seem practical.

Edit: about the PR getting large, I'll wait for the reviewers' feedback, but I could move the new commits from this branch to another and make a new PR, if needed.

Wraith2 · 2022-03-18T18:37:14Z

src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs

+
+            if (_inBytesPacket < 0)
+            {
+#if NETFRAMEWORK


If the netfx version provides better information than the netcore version we should use the netfx approach. Can you trace down whether these cause different messages to be output and if they do identify which is more useful in terms of reporting the error?

Wraith2 · 2022-03-18T18:38:13Z

src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs

+        // NOTE: This method (and all it calls) should be retryable without replaying a snapshot
+        internal bool TryPrepareBuffer()
+        {
+#if NETFRAMEWORK


This one needs input from the MS team. It isn't clear to me why the reliability assertions are not present in the netcore codebase and whether they are obsolete.

There doesn't seem to be any mention of ReliabilitySection in netcore.

Nope. Probably because netcore can't be hosted in sql server because it doesn't contain he reliability infrastructure that neftx does. However what I don't know is whether the netfx version of this library will ever be required to be loaded into sql server, it feels unlikely to me but if it ever was then this stuff would be needed.

Could the reliability stuff be stubbed out as no-ops in netcore or is it in the framework not this library?

I think the reliability stuff should be kept. At least as a no-op, where possible. I'm pretty sure they don't exist in the netcore code because the functions simply weren't supported on netcore when sqlclient was first ported to it. Given the status of .NET Framework and System.Data.SqlClient, I think it might be likely that SQL does eventually adopt .NET and MDS in the database. I'd hate to have to re-create all the reliability code. As it is, it would need a thorough going-through...

With the reliability requirements removed from the netcore codebase I'm pretty sure it's not possible to have netcore run in-process in sql server and never will be.
However I do agree that the reliability code should be kept. It may be possible to continue to use netfx based versions.

Wraith2 · 2022-03-18T18:39:04Z

src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs

+                        _messageStatus = _partialHeaderBuffer[1];
+                        _spid = _partialHeaderBuffer[TdsEnums.SPID_OFFSET] << 8 |
+                                  _partialHeaderBuffer[TdsEnums.SPID_OFFSET + 1];
+#if !NETFRAMEWORK


This is just event logging and i think it should be safe to unconditionally include this in all builds.

Wraith2 · 2022-03-18T18:40:00Z

src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs

+                {
+                    throw;
+                }
+#if NETFRAMEWORK


Can you check if this simply causes event logging output? If it does it can probably be unconditionally included in all builds.

Wraith2 · 2022-08-26T17:36:42Z

Merging on master is best but working on your own branch before it's merged into master you have a choice. I find it cleaner to rebase if there are only a few comments and a lot of changes have happened on the main branch. As long as the result is working code then I'm not sure it really matters.

panoskj · 2022-08-26T21:06:09Z

Thanks @Wraith2, that's what I meant. I almost always prefer rebase over merge for my personal branches.

@JRahnama rebase only affects a single branch in a single repository (e.g. the branch of this PR, which is in my fork). It would not affect this repository at all (in fact, the end result will be the same after merging the PR, since all commits will be squashed into one).

But, since the commits of the PR may change with rebase, you may want to review them again. On the other hand, you may want to review merge commits too. My point is, both ways technically involve reviewing the whole branch again, if you want to be 100% safe.

Though personally, I find merge commits harder to review. It's like reviewing all previous commits squashed into one. But I will stick with whatever works best for the reviewers.

As for github's warning about rebase, I think it is too vague. For example, using rebase to squash commits before merging a PR is not a bad practice, that's essentially what happens in this repository. I think github is only trying to warn those who don't know exactly what they are doing. Because it's very easy to misuse rebase (especially if you have never used it before).

# Conflicts: # src/Microsoft.Data.SqlClient/netcore/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs # src/Microsoft.Data.SqlClient/netfx/src/Microsoft.Data.SqlClient.csproj

…o ignore out parameters, instead of an unused variable.

JRahnama · 2022-11-03T20:58:48Z

/azurepipelines run

azure-pipelines · 2022-11-03T20:58:58Z

Azure Pipelines successfully started running 1 pipeline(s).

src/Microsoft.Data.SqlClient/netfx/src/Microsoft/Data/SqlClient/SqlUtil.cs

src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs

Co-authored-by: Lawrence Cheung <[email protected]>

…Object

…would maybe help to start working on fix the async bug.

panoskj added 6 commits February 21, 2022 11:10

Merging common fields, properties and types of TdsParserStateObject.

22c25f5

Merging common type NullBitmap of TdsParserStateObject.

4ec17f6

Merging a few methods of TdsParserStateObject.

de83b8d

Merging constructor of TdsParserStateObject.

d15a7d3

Merging some methods of TdsParserStateObject.

927e4a6

Merging ObjectID property of TdsParserStateObject.

2c81d54

DavoudEshtehari added the ➕ Code Health Issues/PRs that are targeted to source code quality improvements. label Mar 2, 2022

DavoudEshtehari added this to the 5.0.0-preview2 milestone Mar 2, 2022

Merge remote-tracking branch 'upstream/main' into MergeTdsParserState…

72d8e54

…Object # Conflicts: # src/Microsoft.Data.SqlClient/netcore/src/Microsoft.Data.SqlClient.csproj # src/Microsoft.Data.SqlClient/netfx/src/Microsoft.Data.SqlClient.csproj

DavoudEshtehari reviewed Mar 15, 2022

View reviewed changes

DavoudEshtehari requested review from JRahnama, johnnypham and Kaur-Parminder March 15, 2022 22:52

DavoudEshtehari mentioned this pull request Mar 15, 2022

Possible mergeable classes for merging code bases #1261

Open

panoskj added 2 commits March 18, 2022 16:51

Merging some methods of TdsParserStateObject (note: ports part of dot…

417a6da

…net#1060 from netcore to common file).

Merging some methods of TdsParserStateObject (note: uses some #if dir…

b8eb31d

…ectives).

Wraith2 reviewed Mar 18, 2022

View reviewed changes

DavoudEshtehari modified the milestones: 5.0.0-preview2, 5.0.0-preview3 Apr 6, 2022

lcheunglci mentioned this pull request Apr 26, 2022

Merge to shared - TdsParserSessionPool #1595

Merged

DavoudEshtehari modified the milestones: Future, 5.1.0-preview1, 5.1.0-preview2 Sep 30, 2022

DavoudEshtehari mentioned this pull request Sep 30, 2022

Add and use TryReadChars method #1544

Merged

lcheunglci closed this Oct 4, 2022

lcheunglci reopened this Oct 4, 2022

panoskj added 7 commits October 5, 2022 11:09

Merge branch 'main' into MergeTdsParserStateObject

ed279eb

# Conflicts: # src/Microsoft.Data.SqlClient/netcore/src/Microsoft/Data/SqlClient/TdsParserStateObject.cs # src/Microsoft.Data.SqlClient/netfx/src/Microsoft.Data.SqlClient.csproj

TdsParserStateObject: Fixed naming rules violations.

4e6ed9a

TdsParserStateObject: Removed unnecessary assignments. Used discard t…

315acb1

…o ignore out parameters, instead of an unused variable.

TdsParserStateObject: Simplified names.

87f0cba

TdsParserStateObject: Simplified default expression.

d71028b

TdsParserStateObject: Removed unnecessary casts.

3e05aeb

TdsParserStateObject: Replaced var usages with explicit types.

58ae136

panoskj changed the title ~~[WIP] Merge common code bases for TdsParserStateObject.cs~~ Merge common code bases for TdsParserStateObject.cs Oct 10, 2022

lcheunglci reviewed Nov 8, 2022

View reviewed changes

DavoudEshtehari and others added 2 commits November 8, 2022 11:38

Apply suggestions from code review

5eb4a61

Co-authored-by: Lawrence Cheung <[email protected]>

Merge remote-tracking branch 'upstream/main' into MergeTdsParserState…

f75d911

…Object

lcheunglci approved these changes Nov 8, 2022

View reviewed changes

Address comments

0b4c345

DavoudEshtehari approved these changes Nov 9, 2022

View reviewed changes

JRahnama approved these changes Nov 10, 2022

View reviewed changes

JRahnama merged commit e316a68 into dotnet:main Nov 10, 2022

bhugot pushed a commit to bhugot/SqlClient that referenced this pull request Nov 21, 2022

I merged more methods from TdsParserStateObject after dotnet#1520 It …

79c2f1d

…would maybe help to start working on fix the async bug.

bhugot mentioned this pull request Nov 21, 2022

Merge more methods from TdsParserStateObject #1843

Closed

panoskj mentioned this pull request Nov 22, 2022

Merge common code bases for TdsParserStateObject.cs (2) #1844

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge common code bases for TdsParserStateObject.cs #1520

Merge common code bases for TdsParserStateObject.cs #1520

panoskj commented Feb 21, 2022

dnfadmin commented Feb 21, 2022 •

edited

Loading

Wraith2 commented Feb 23, 2022

Wraith2 commented Mar 2, 2022

DavoudEshtehari commented Mar 2, 2022

DavoudEshtehari left a comment

panoskj commented Mar 18, 2022 •

edited

Loading

Wraith2 commented Mar 18, 2022

panoskj commented Mar 18, 2022 •

edited

Loading

Wraith2 Mar 18, 2022

Wraith2 Mar 18, 2022

johnnypham Mar 18, 2022

Wraith2 Mar 18, 2022

David-Engel Aug 18, 2022

Wraith2 Aug 18, 2022

Wraith2 Mar 18, 2022

Wraith2 Mar 18, 2022

Wraith2 commented Aug 26, 2022

panoskj commented Aug 26, 2022 •

edited

Loading

JRahnama commented Nov 3, 2022

azure-pipelines bot commented Nov 3, 2022

Merge common code bases for TdsParserStateObject.cs #1520

Merge common code bases for TdsParserStateObject.cs #1520

Conversation

panoskj commented Feb 21, 2022

dnfadmin commented Feb 21, 2022 • edited Loading

Wraith2 commented Feb 23, 2022

Wraith2 commented Mar 2, 2022

DavoudEshtehari commented Mar 2, 2022

DavoudEshtehari left a comment

Choose a reason for hiding this comment

panoskj commented Mar 18, 2022 • edited Loading

Wraith2 commented Mar 18, 2022

panoskj commented Mar 18, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Wraith2 commented Aug 26, 2022

panoskj commented Aug 26, 2022 • edited Loading

JRahnama commented Nov 3, 2022

azure-pipelines bot commented Nov 3, 2022

dnfadmin commented Feb 21, 2022 •

edited

Loading

panoskj commented Mar 18, 2022 •

edited

Loading

panoskj commented Mar 18, 2022 •

edited

Loading

panoskj commented Aug 26, 2022 •

edited

Loading