Add support for SAP HANA #1662

breglerj · 2018-04-13T09:17:18Z

add row and column store dialects
add driver
add batcher
add configuration template
exclude tests that are known not to run on SAP HANA

fredericDelaporte · 2018-04-13T10:38:34Z

Related discussion from here:

I came across this issue while implementing an NHibernate dialect for SAP HANA. HANA needs the table name when retrieving the last generated identity value. I'm planning on contributing the dialect once I'm done. Would that be ok with you?

@fredericDelaporte

Since NHibernate already have three series of dialects for SAP products (ASE, ASA and SQL Anywhere, all seemingly originating from Sybase), I was wondering if a fourth one was really due, but it seems SAP HANA is actually another distinct database system.

So I understand it needs a dedicated dialect, and likely a dedicated driver too.

The way built-in dialects and drivers are included directly in NHibernate core is somewhat a legacy, from times where NuGet was not a de facto standard way of distributing software. And it has drawbacks, like drivers relying on reflection for avoiding taking a hard dependency on data providers of every database system. It also has the trouble of either being untested by the CI, or complicating further the CI by adding another database to test.

So instead of contributing the dialect/driver directly into NHibernate core, you may consider contributing them as a separated project within its own GitHub repository, yielding a dedicated NuGet package which could then take direct dependencies on the data provider. There is some work ongoing for splitting drivers (not yet dialects) out of NHibernate: #626. You can have a look at this PR to see in which direction the dialect/driver area is currently heading.

@breglerj

Yes, HANA is a completely separate database and like you said it needs its own driver and dialect (actually two, one for the SAP HANA column store and one for the SAP HANA row store). The dialects will be more or less straight ports of the Hibernate HANA dialects.

I agree that having the drivers and dialects as separate packages is a good idea. However, for organizational reasons it is going to be extremely difficult for me to get approval to provide the HANA driver and dialects as a new GitHub project, especially because NHibernate is licensed under the LGPL. In addition, the HANA data provider isn't available via NuGet. So my proposal would be to contribute the minimum required functionality for NHibernate to work with HANA to the NHibernate core as a short-term solution. Once the drivers have been moved out of the NHibernate core I could then try to relocate the HANA driver to a separate project as well. Would that work for you?

@fredericDelaporte

We should not use the bug report here to discuss another feature. There is the development group for this. Or create an issue about HANA dialect/driver (eventually directly a PR if you already have done the code, we do no more mandate a separated issue).

fredericDelaporte

That looks like a lot of work, and so a lot to review. Changes to test should be minimized as explained in code review comments. I have not reviewed them overall. (That is indeed just a preliminary review.)

fredericDelaporte · 2018-04-15T10:40:58Z

src/NHibernate.Test/Criteria/Lambda/FunctionsIntegrationFixture.cs

 using NUnit.Framework;

 namespace NHibernate.Test.Criteria.Lambda
 {
 	[TestFixture]
 	public class FunctionsIntegrationFixture : TestCase
 	{
+		protected override bool AppliesTo(Dialect.Dialect dialect)
+		{
+			return !(dialect is AbstractHanaDialect); // HANA does not support inserting a row without specifying any column values


It looks to me the same comment has been copied-pasted, without it to stay relevant.

Moreover, we favor a kind of "feature detection" over dialect/driver detection for disabling tests: it tends to bloat far less the history with changes.

By example, for "support inserting a row without specifying any column values", there is TestDialect.SupportsEmptyInserts. To tell HANA dialect does not support it, add a HanaColumnStoreTestDialect (that is based on name) in TestDialectfolder of NHibernate.Test, implemented similarly to the other "TestDialect" there, and overriding this property to false. Then any test relying on this feature will be ignored without needing to change them.

For some other features, there are properties from the base Dialect class to override.

Some cases are still handled through dialect/driver sniffing, but no new case should be introduced.

The comment should be relevant everywhere that I've copied it. There are quite a lot of tests that have a parent entity with only an ID attribute and a child collection. The generated INSERT statement for such a mapping looks something like INSERT INTO Parent VALUES (). The empty parentheses cause a SQL error on HANA, that's why the tests have to be skipped.

I did see TestDialect.SupportsEmptyInserts. In fact, the PR already includes TestDialect implementations for all HANA dialects. I just wasn't sure that this property covers the exact use case I'm facing. I'll push a new change replacing the explicit checks for the HANA dialect with a check for this property.

fredericDelaporte · 2018-04-15T11:05:42Z

src/NHibernate/Dialect/Function/SQLFunctionTemplateWithRequiredParameters.cs

+	/// Each dialect will define a template as a string (exactly like above) marking function 
+	/// parameters with '?' followed by parameter's index (first index is 1).
+	/// </summary>
+	[Serializable]


Rather than copying comment from base, use <inheritdoc />. Or even better, document what it changes compared to its base class. Indeed that is the comment from StandardSQLFunctionWithRequiredParameters which should be copied here, slightly adjusted like A template-based SQL function which substitutes required missing parameters with defaults.

I'll adjust the documentation.

fredericDelaporte · 2018-04-15T11:15:58Z

src/NHibernate/Dialect/Function/SQLFunctionTemplateWithRequiredParameters.cs

+	{
+		private readonly object[] _requiredArgs;
+
+		public SQLFunctionTemplateWithRequiredParameters(IType type, string template, object[] requiredArgs) : base(type, template)


Better also add an overload for allowing supplying hasParenthesesIfNoArgs.

fredericDelaporte · 2018-04-15T11:20:41Z

src/NHibernate/Dialect/Dialect.cs

@@ -2480,6 +2480,14 @@ public virtual string AddColumnString
 			get { throw new NotSupportedException("No add column syntax supported by Dialect"); }
 		}

+		/// <summary>
+		/// The syntax for the suffix used to add a column to a table. Note this is deprecated


The "Note" copied from AddColumnString own comment seems to be a note for some deprecation which does not seem to be done NHibernate side. Better remove that note in this new property comment.

I just added the deprecation note because it was already present on AddColumnString and AddColumnSuffixString doesn't make sense without AddColumnString. Do you want me to remove the deprecation note on both properties? Having the deprecation note on only one property seems wrong to me.

A correct deprecation note is the Obsolete attribute anyway. Ok for removing both.

- Replace explicit check for AbstractHanaDialect with TestDialect.SupportsEmptyInserts where applicable - Replace copied base class documentation with <inheritdoc /> - Add constructor SQLFunctionTemplateWithRequiredParameters(IType, string, object[], bool) - Improve documentation of SQLFunctionTemplateWithRequiredParameters - Removed deprecation comments from Dialect#AddColumnString and Dialect#AddColumnSuffixString

fredericDelaporte · 2018-04-16T11:48:49Z

src/NHibernate.Test/Async/Criteria/Lambda/FunctionsIntegrationFixture.cs

@@ -22,7 +22,7 @@ public class FunctionsIntegrationFixtureAsync : TestCase
 	{
 		protected override bool AppliesTo(Dialect.Dialect dialect)
 		{
-			return !(dialect is AbstractHanaDialect); // HANA does not support inserting a row without specifying any column values
+			return TestDialect.SupportsEmptyInserts;


This surprises me, because we already test a database which is not supposed to support this, and which does not fail in all these tests modified by this PR. I have to check what is going on.

Ok, the test uses the native generator, which resolves to identity if it is supported, otherwise sequence if supported, otherwise hilo. The other db not supporting empty inserts does override NativeIdentifierGeneratorClass for using hilo, thus it has a value to insert.

Then the exact condition here should be TestDialect.SupportsEmptyInserts || dialect.NativeIdentifierGeneratorClass != typeof(IdentityGenerator).

Shouldn't the check for the NativeIdentifierGeneratorClass be included in TestDialect.SupportsEmptyInserts then? It seems strange that you'd have to check for TestDialect.SupportsEmptyInserts and basically everywhere add the check for the NativeIdentifierGeneratorClass right after it. If TestDialect.SupportsEmptyInserts really means something else, would it make sense to introduce a new property like TestDialect.SupportsEmptyInsertsWithNativeIdentifierGenerator?

If the mapped class was using identity directly instead, testing on NativeIdentifierGeneratorClass inside SupportsEmptyInserts would defeat its purpose.

The test here does empty inserts only if the native generator does resolves to identity, otherwise it does not perform empty inserts. So when the dialect does not support empty inserts but does not resolves native to identity, it is irrelevant to disable that test.

SupportsEmptyInsertsWithNativeIdentifierGenerator is not meaningful. But since the case is very frequent, why not adding a SupportsEmptyInsertsOrHasNonIdentityNativeGenerator. It could be something like:

/// <summary> /// Either supports inserting in a table without any column specified in the insert, or has a native /// generator strategy resolving to something else than identity. /// </summary> /// <remarks>This property is useful for cases where empty inserts happens only when the entities /// generator is <c>native</c> while the dialect uses <c>identity</c> for this generator.</remarks> public bool SupportsEmptyInsertsOrHasNonIdentityNativeGenerator => SupportsEmptyInserts || _dialect.NativeIdentifierGeneratorClass != typeof(IdentityGenerator);

This new property can be used to exclude tests where empty inserts happen only when the entities generator is native while the dialect uses identity for this generator and empty inserts aren't supported by the database.

fredericDelaporte · 2018-04-24T23:02:22Z

I am in the process of reviewing this. I have noticed that multi-threaded tests get unexpected failures of the SAP HANA connection opening, like NH1908ThreadSafety or NH2192 tests. Of course these tests do not share a connection between many threads. They are opening distinct connections on many threads. If this is not well supported by the HANA .Net provider, this is very limiting.

breglerj · 2018-04-25T07:52:26Z

That's strange. The multi-threaded tests run fine on my machine. How do you run the tests? What kind of failures are you getting? Which version of the HANA .Net data provider do you use?

fredericDelaporte · 2018-04-25T15:07:04Z

I am running them through JetBrain Rider IDE, with as database a SAP HANA express edition 2.0 SPS03 server-only VM, as client Sap.Data.Hana 2.3.78.0 installed under C:\Program Files\sap\hdbclient, obtained from HXEDownloadManager by selecting "Clients (Windows)", then using content of hdb_client_windows_x86_64.zip.

In the case of NH2192, I have always seen the failure with HqlIsThreadsafe_UsingThreads test, but only sometimes with HqlIsThreadsafe_UsingPool test. Both failures are caused by following exception:

System.Runtime.InteropServices.SEHException: Un composant externe a levé une exception.
   à Sap.Data.Hana.HanaConnection.Open()

In English this would likely be:

System.Runtime.InteropServices.SEHException: External component has thrown an exception.
   at Sap.Data.Hana.HanaConnection.Open()

The ErrorCode property of the exception has the value -2147467259.

I have tried having the provider files directly loaded instead of relying on having them in the GAC, copying directly files listed in HanaDriver xml comment. No changes if not having uninstalled the client and removed things from GAC, otherwise no more working at all for all tests. (System.Exception: The specified module could not be found at Sap.Data.Hana.HanaUnmanagedDll.LoadDll(String dllPath), while attempting to load libadonetHDB.dll, with a correct dllPath.)

fredericDelaporte

See breglerj#1 for proposed modifications for handling a part of the review comments.

fredericDelaporte · 2018-04-23T12:38:42Z

src/NHibernate/Dialect/AbstractHanaDialect.cs

+		/// <inheritdoc />
+		public override string NoColumnsInsertString
+		{
+			get { throw new MappingException("HANA does not support inserting a row without specifying any column values"); }


Removing this override allows numerous otherwise failing tests to pass. The property is called by NHibernate for preparing insert statements in advance, without having already actual inserts to perform. Some tests re-use mapping having entities with just a native id, but without having to insert such entities. With the exception thrown here, it causes such test to fail while they would have succeeded otherwise.

Of course the mapping has still a non-supported part, so it makes sens to reject it that way. But this represents a discrepancy in behavior with other dialects not supporting empty inserts, and causes many additional changes in tests. Moreover if some future version of HANA starts supporting empty inserts with the default syntax generated by NHibernate, this will prevents the use of the feature till the dialect is changed.

So I think it is better here to not override the property and let SAP HANA handle the case (raising an error currently) itself.

I'll remove the override. Although even if HANA supports this in a future version it's not guaranteed that it'll use the syntax values( ) it still makes sense for the tests.

fredericDelaporte · 2018-04-23T14:08:40Z

src/NHibernate/AdoNet/HanaBatchingBatcher.cs

+namespace NHibernate.AdoNet
+{
+	/// <summary>
+	/// Summary description for HanaBatchingBatcher.


Even if it may be copied from another batcher, please put a more meaningful xml comment, like "Batcher for SAP HANA."

fredericDelaporte · 2018-04-23T14:11:16Z

src/NHibernate/AdoNet/HanaBatchingBatcher.cs

+
+		public override void AddToBatch(IExpectation expectation)
+		{
+			Debug.Assert(CurrentCommand is ICloneable); // HanaCommands are cloneable


Using Debug.Assert is not part of NHibernate practices. Throw an InvalidOperationException instead for this case (if the command is not cloneable), if you want this to be checked here.

Well, there are some other cases, but there are likewise many things we are changing/modernizing/fixing, and so we avoid new occurrences to be added. Another case is the Java naming, we try to avoid having more of it to be added and ask for things to be renamed according to .Net usual conventions. (It appears private field are no more covered by public guidelines, but previously they were.)

fredericDelaporte · 2018-04-23T14:14:45Z

src/NHibernate/AdoNet/HanaBatchingBatcher.cs

+			if (_currentBatch == null)
+			{
+				// use first command as the batching command
+				_currentBatch = (batchUpdate as ICloneable).Clone() as DbCommand;


Do not use the as cast when the cast is never supposed to fail: it results in a null reference exception when it fails, instead of throwing a way more obvious invalid cast exception. Use ((ICloneable)batchUpdate) instead.

fredericDelaporte · 2018-04-23T14:19:44Z

src/NHibernate/AdoNet/HanaBatchingBatcher.cs

+				_currentBatch = (batchUpdate as ICloneable).Clone() as DbCommand;
+			}
+
+			_currentBatchCommands.Add((batchUpdate as ICloneable).Clone() as DbCommand);


Same as above. But rather than casting at three places (including the initial check), better do that once in the initial check, like:

if (!(CurrentCommand is ICloneable cloneableCurrentCommand)) throw new InvalidOperationException("Current command is not an ICloneable");

And then just use cloneableCurrentCommand without any cast anymore.

fredericDelaporte · 2018-04-25T16:45:49Z

src/NHibernate/Dialect/AbstractHanaDialect.cs

+		public override bool SupportsRowValueConstructorSyntaxInInList => true;
+
+		/// <inheritdoc />
+		public override bool SupportsCircularCascadeDeleteConstraints => false;


The only test relying on this succeeds when this is set as true. Am I missing something?

I copied this from the Hibernate dialect. This was the case in older releases, but apparently it is supported now.

fredericDelaporte · 2018-04-25T16:48:30Z

src/NHibernate/Dialect/AbstractHanaDialect.cs

+		public override bool SupportsCircularCascadeDeleteConstraints => false;
+
+		/// <inheritdoc />
+		public override bool SupportsExpectedLobUsagePattern => false;


It seems many overrides have been taken from Hibernate. NHibernate side, this one does not change anything.

fredericDelaporte · 2018-04-25T16:50:31Z

src/NHibernate/Dialect/AbstractHanaDialect.cs

+
+		#endregion
+
+


Double blank line.

fredericDelaporte · 2018-04-25T16:50:47Z

src/NHibernate/Dialect/AbstractHanaDialect.cs

+		/// <inheritdoc />
+		public override string SelectGUIDString
+		{
+			get { return "select sysuuid from dummy"; }


Adding sys. would be safer.

For the same reasons as with sequence values, it doesn't matter here because there isn't actually anything being selected from the table.

It does still matter. If there is no row in the table, it will not return anything.

Looks like you're right. It should be changed to sys.dummy.

fredericDelaporte · 2018-04-25T16:58:33Z

src/NHibernate/Dialect/AbstractHanaDialect.cs

+		public override bool SupportsExistsInSelect => false;
+
+		/// <inheritdoc />
+		public override bool SupportsScalarSubSelects => false;


It seems to support them indeed. But some tests relying on this fail for other reasons. This needs more investigations. It looks like this is ordering by an aggregating scalar sub-selecting which are not supported (and it looks like a HANA bug).

Partially address the review.

Do some more reformatting, fix some more tab/spaces mixup.

Adjust code according to review

fredericDelaporte · 2018-04-26T14:13:02Z

I have now added a commit for handling the remaining scalar sub-selects failures.
This leaves the following points:

Implementation questions:
- Should Dialect.AddIdentifierOutParameterToInsert be implemented on HanaDialectBase?
- Should SupportsMultipleOpenReaders be overridden to false? Normally there are some test which would failed if this was not supported and overridden to false, especially those using multiple calls to IQuery.Enumerable without disposing them (which is a bit tricky to determine, because their implementation causes foreach loop to dispose them). In doubt, overriding it to false is safer, but may have a performance impact.
Failing tests to investigate:
- Insertordering.FamilyModel.Fixture.CircularReferences
- Legacy.FooBarTest:
  - CollectionsInSelect
  - FindByCriteria
  - UpdateFromTransient
- Linq:
  - PropertyMethodMappingTests.CanExecuteCountInSelectClause
  - SelectionTests.CanSelectWithAggregateSubQuery
- NH2192.HqlIsThreadsafe_UsingThreads
- NH2244.LinqComponentTypeEquality
- NH2394.LinqUserTypeEquality
- NH280.ConstInSelect
- Properties:
  - CompositePropertyRefTest
  - DynamicEntityTest

breglerj · 2018-04-26T15:23:22Z

Should Dialect.AddIdentifierOutParameterToInsert be implemented on HanaDialectBase?

HANA doesn't support returning values from INSERT statements, so this is currently not possible.

Should SupportsMultipleOpenReaders be overridden to false? Normally there are some test which would failed if this was not supported and overridden to false, especially those using multiple calls to IQuery.Enumerable without disposing them (which is a bit tricky to determine, because their implementation causes foreach loop to dispose them). In doubt, overriding it to false is safer, but may have a performance impact.

I would suggest leaving it set to false for now. If there are complaints that the performance is not good enough I would revisit this.

Regarding the test failures:

Insertordering.FamilyModel.Fixture.CircularReferences

I'll have to investigate further.

Legacy.FooBarTest:

CollectionsInSelect

FindByCriteria

UpdateFromTransient

CollectionsInSelect already has a section which is excluded on Oracle and MSSQL CE. Adding HANA as well allows the test to pass.
FindByCriteria fails because of a HANA bug. This will be fixed in one of the next revisions.
UpdateFromTransient fails for the same reason as Insertordering.FamilyModel.Fixture.CircularReferences.

Linq:

PropertyMethodMappingTests.CanExecuteCountInSelectClause

SelectionTests.CanSelectWithAggregateSubQuery

These test fail because there is no ordering specified and HANA doesn't return the results in the expected order. Adding an ORDER BY clause fixes these tests

NH2192.HqlIsThreadsafe_UsingThreads

I still can't reproduce the failure. I'll have to investigate further.

NH2244.LinqComponentTypeEquality

I can't really explain this one. The failure originates in the SqlGenerator. The PhoneNumberUserType used in the test returns a column span of 2 which causes an IEnumerable.Single() to fail. So far I don't see how this is specific to HANA.

NH2394.LinqUserTypeEquality

Same root cause as NH2244.LinqComponentTypeEquality

NH280.ConstInSelect

This seems to be related to the data provider. I'll have to check.

Properties:

CompositePropertyRefTest

DynamicEntityTest

Foreign key constraints over unique columns weren't supported until HANA 2 SP3. I'll have to investigate why the tests still fail.

breglerj · 2018-04-27T14:57:16Z

Here is an update regarding the failing tests:

Insertordering.FamilyModel.Fixture.CircularReferences

This failure only happens when using the HANA batcher. When using the NonBatchingBatcher the test succeeds. My guess is that something needs to be fixed in the HANA data provider. I'm waiting for feedback from the data provider developers.

Legacy.FooBarTest:

CollectionsInSelect

FindByCriteria

UpdateFromTransient

CollectionsInSelect passes with the latest commit.
FindByCriteria fails because of a HANA bug. This will be fixed in one of the next revisions.
UpdateFromTransient fails for the same reason as Insertordering.FamilyModel.Fixture.CircularReferences.

Linq:

PropertyMethodMappingTests.CanExecuteCountInSelectClause

SelectionTests.CanSelectWithAggregateSubQuery

These tests pass with the latest commit.

NH2192.HqlIsThreadsafe_UsingThreads

This seems to be a bug in the HANA data provider. I've filed a bug report for this.

NH2244.LinqComponentTypeEquality

I still can't really explain this one. The failure originates in the SqlGenerator. The PhoneNumberUserType used in the test returns a column span of 2 which causes an IEnumerable.Single() to fail. So far I don't see how this is specific to HANA.

NH2394.LinqUserTypeEquality

Same root cause as NH2244.LinqComponentTypeEquality

NH280.ConstInSelect

This seems to be a bug in the HANA data provider. I've filed a bug report for this.

Properties:

CompositePropertyRefTest

DynamicEntityTest

This is most likely a bug in HANA. The error happens when defining foreign key constraints to unique columns involving a BOOLEAN column. I've filed a bug report for this.

fredericDelaporte · 2018-04-30T11:59:18Z

If possible, it would be great to have public link to the HANA bug reports causing each failing test. It would allow to check if the bug status has evolved.

About NH2294 and NH2394, their failure appears to be due to overriding SupportsRowValueConstructorSyntax to true. It appears NHibernate supports of this feature does not work, at least for these two tests. In NHibernate, no dialect excepted HANA are switching this property to true. Removing its override (so keeping it false) allows this two tests to pass.

I think SupportsRowValueConstructorSyntax is bugged in NHibernate. Maybe this has been fixed on Hibernate side. Or maybe it works (seen any HQL query benefiting of it?) but not with LINQ, which is NHibernate specific.

fredericDelaporte · 2018-04-30T13:16:10Z

The row-store case needs more work too: more than hundred tests fail for it, because row-store seems to support less features than column store. By example: feature not supported: select-for-update can support multiple tables only of column type. So the row store dialect needs specific overrides for such features.

breglerj · 2018-05-02T08:22:58Z

Unfortunately the HANA bug reports aren't publically available.

NHibernate performs backtracking for parameter specifications which is where the error in NH2294 and NH2394 originates. Hibernate doesn't do the backtracking which is why it works there. I'm fine with removing the override of SupportsRowValueConstructorSyntax from the HANA dialects for now since it doesn't affect the functionality. Removing the override just triggers an unnecessary query rewrite. Should I open an NHibernate ticket for this?

fredericDelaporte · 2018-05-02T14:26:14Z

Yes, better add an issue for that trouble with SupportsRowValueConstructorSyntax.

- Add separate drivers for row and column stores since the row store doesn't support system transactions - Disable support for distributed transactions and select for update on multiple tabled in the row store dialect - Skip NHibernate.Test.ReadOnly.TextHolder because the HANA row store doesn't support the TEXT data type

breglerj · 2018-05-02T14:48:02Z

I've added issue #1676

breglerj · 2018-05-02T14:52:00Z

I've pushed another change which should fix the HANA row store errors. It looks like the HANA row store doesn't support system transactions at all, so I've created a separate driver disabling system transaction support. In addition I've disabled distributed transaction support in the HANA row store dialect as well as support for outer join for update. With these changes alltests pass with the exception of a known few related to bugs in the HANA data provider or server.

fredericDelaporte · 2018-05-07T16:56:39Z

This failure only happens when using the HANA batcher. When using the NonBatchingBatcher the test succeeds. My guess is that something needs to be fixed in the HANA data provider. I'm waiting for feedback from the data provider developers.

Insertordering.FamilyModel.Fixture.CircularReferences and Legacy.FooBarTest.UpdateFromTransient do not fail with a row store. It seems the batching bug is specific to column stores.

The querying bug with Legacy.FooBarTest.FindByCriteria does also occurs only with a column store. In order to ignore it properly with some meaningful TestDialect property, can you give more information about the bug preventing it to work? You wrote it will be fix in a next HANA revision, so I guess this bug is clearly identified. With my last commit, it is the last failing test.

breglerj · 2018-05-07T20:17:21Z

Insertordering.FamilyModel.Fixture.CircularReferences and Legacy.FooBarTest.UpdateFromTransient do not fail with a row store. It seems the batching bug is specific to column stores.

That's interesting. I'll add it to the bug report.

The querying bug with Legacy.FooBarTest.FindByCriteria does also occurs only with a column store. In order to ignore it properly with some meaningful TestDialect property, can you give more information about the bug preventing it to work? You wrote it will be fix in a next HANA revision, so I guess this bug is clearly identified. With my last commit, it is the last failing test.

The error is caused by the column named @@##integer_ * of the entity Foo. The trailing * of the column name is treated as a wildcard which eventually leads to the failure. Since the next HANA revision will contain a fix I don't think it's worth creating a TestDialect property for it. A workaround would be to remove the * from the column name.

breglerj · 2018-05-09T11:09:29Z

@fredericDelaporte Thanks for merging and thanks for all your help. I really appreciate it.

fredericDelaporte · 2018-05-09T11:27:30Z

Thanks for your sustained effort with this PR too. Not every contributor are ready to this.

breglerj · 2018-09-06T12:02:45Z

@fredericDelaporte Do you have an estimate when there is going to be an official release (5.2 ?) containing this PR?

breglerj added 2 commits April 13, 2018 10:40

Add support for SAP HANA

ed54937

Add SAP HANA batcher

34a46e3

fredericDelaporte added t: New Feature c: DataProviders / Dialects p: Minor labels Apr 13, 2018

fredericDelaporte reviewed Apr 15, 2018

View reviewed changes

fredericDelaporte reviewed Apr 16, 2018

View reviewed changes

fredericDelaporte reviewed Apr 25, 2018

View reviewed changes

fredericDelaporte mentioned this pull request Apr 26, 2018

Adjust code according to review breglerj/nhibernate-core#1

Merged

fredericDelaporte and others added 6 commits April 26, 2018 13:05

Adjust code according to review

e07c6ce

Partially address the review.

Adjust some more code according to review

341e217

Do some more reformatting, fix some more tab/spaces mixup.

Retake/redo some changes reverted in excess

9566ee4

Add a comment for the batcher implementation

90055a4

Merge pull request #1 from fredericDelaporte/hana

8f65834

Adjust code according to review

Handle scalar sub-select failure cases

ab23ff1

Address more PR review comments.

51d094b

Ignore more unsupported tests for Hana

4ae2055

fredericDelaporte added this to the 5.2 milestone May 8, 2018

fredericDelaporte approved these changes May 8, 2018

View reviewed changes

Merge branch 'master' into nhibernatehanasupport

3e8ba0f

hazzik approved these changes May 8, 2018

View reviewed changes

fredericDelaporte merged commit 1ebebd5 into nhibernate:master May 9, 2018

fredericDelaporte added the r: Fixed label May 9, 2018

fredericDelaporte mentioned this pull request Sep 21, 2018

Add SQL Anywhere 17 support #1854

Merged

fredericDelaporte mentioned this pull request Feb 28, 2020

How about create a sqlite driver with Microsoft.Data.Sqlite.Core ? #2318

Closed

Add support for SAP HANA #1662

Add support for SAP HANA #1662

Uh oh!

Conversation

breglerj commented Apr 13, 2018

Uh oh!

fredericDelaporte commented Apr 13, 2018

Uh oh!

fredericDelaporte left a comment

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte Apr 15, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte commented Apr 24, 2018

Uh oh!

breglerj commented Apr 25, 2018

Uh oh!

fredericDelaporte commented Apr 25, 2018

Uh oh!

fredericDelaporte left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fredericDelaporte Apr 23, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

fredericDelaporte Apr 15, 2018 •

edited

Loading

fredericDelaporte left a comment •

edited

Loading

fredericDelaporte Apr 23, 2018 •

edited

Loading

fredericDelaporte commented Apr 30, 2018 •

edited

Loading

fredericDelaporte commented May 7, 2018 •

edited

Loading