Skip to content

Updating DatabaseLoader to support getting column info from a given .NET type. #4091

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Aug 12, 2019
Merged

Updating DatabaseLoader to support getting column info from a given .NET type. #4091

merged 4 commits into from
Aug 12, 2019

Conversation

tannergooding
Copy link
Member

This adds limited support for determining the column info from a .NET type in order to match what TextLoader provides.

return DbType.Boolean;
}

case InternalDataKind.DT:
Copy link
Member

@eerhardt eerhardt Aug 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about DateTimeOffset (InternalDataKind.DZ) and TimeSpan (InternalDataKind.TS) ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no equivalent for DbKind

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even DbType.DateTimeOffset and DbType.Time?

https://docs.microsoft.com/en-us/dotnet/api/system.data.dbtype

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latter is the SQL time type, not an equivalent to the System.TimeSpan type; I'm not sure what the appropriate conversion is. I missed DateTimeOffset.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latter is the SQL time type, not an equivalent to the System.TimeSpan type;

According to https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql-server-data-type-mappings, it is the appropriate mapping:

SQL Server Database Engine type .NET Framework type SqlDbType enumeration SqlDataReader SqlTypes typed accessor DbType enumeration SqlDataReader DbType typed accessor
time(SQL Server 2008 and later) TimeSpan Time none Time GetDateTime

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that also the appropriate mapping for all database types, not just SQL?

Also, it looks like it isn't even the SQL time type, it is the SQL datetime type and there is a separate value in a separate enum that should be used for SQL time:

| Time | 17 | A type representing a SQL Server DateTime value. If you want to use a SQL Server time value, use Time. |

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, right.
These weren't done because DbDataReader doesn't expose Get methods for them

public int? Max;

/// <summary>
/// Whether this range extends to the end of the line, but should be a fixed number of items.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "to the end of the line" mean to a database loader?

I think we should remove these options until we decide we have data that says they are required. That way they don't "sneak" in to the product, and don't do anything.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case it would mean to the end of the table. I'm pretty sure it is used for vector support.

@tannergooding
Copy link
Member Author

@eerhardt, any other feedback here or can it be merged and I can start on getting the vector support up?

@eerhardt
Copy link
Member

@eerhardt, any other feedback here or can it be merged

I don't believe that this feedback has been addressed:

I think we should remove these options until we decide we have data that says they are required.

We shouldn't be adding public options that aren't being used. You can easily add these new options if and when they get supported.

@tannergooding
Copy link
Member Author

We shouldn't be adding public options that aren't being used. You can easily add these new options if and when they get supported.

They are going to be used in the next PR which adds the vector support. Is it really worthwhile to pull it out and retrigger CI just for it to be used and re-added in the following PR?

@eerhardt eerhardt merged commit e34f2e1 into dotnet:master Aug 12, 2019
@ghost ghost locked as resolved and limited conversation to collaborators Mar 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants