Skip to content
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

experiment addition of schema support #1

Open
wants to merge 6 commits into
base: paket-and-new-dotnetsdk-for-main-solution
Choose a base branch
from

Conversation

smoothdeveloper
Copy link
Owner

No description provided.

@@ -64,6 +69,8 @@ type private ModelChange(model : Model, inference : ITypeInferenceContext) =
return! ModelOps.dropView objName
| DropTable ->
return! ModelOps.dropTable objName
| DropSchema ->
return! ModelOps.dropSchema { Value = Some drop.ObjectName.ObjectName; Source = objName.Source }
Copy link
Owner Author

Choose a reason for hiding this comment

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

@rspeele: Note that it is ObjectName rather than SchemaName (used for schema qualified objects).

@@ -280,6 +284,10 @@ and [<NoComparison>]
/// Resolve a reference to a table which may occur as part of a TableExpr.
/// This will resolve against the database model and CTEs, but not table aliases defined in the FROM clause.
member this.ResolveObjectReference(name : ObjectName, inferView) =
match this.Model.Schema (Some name.ObjectName) with
Copy link
Owner Author

Choose a reason for hiding this comment

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

@rspeele: This is simplest thing that seems to work.

I'm prepending any object resolution here, which may have an impact (no test failing though), should I only do that when the name.SchemaName is empty? or should it be handled another way?

@rspeele
Copy link

rspeele commented Nov 20, 2019

Sorry I haven't had much time to look at this.

I think resolving object name resolution like this might have problems if e.g. somebody makes a table in the default schema whose name collides with a schema name, then tries to drop that table. E.g. in sqlite create table main; drop table main might blow up during ResolveObjectReference since main is the default schema in that backend.

I see for create schema, which is its own statement, you had the schema name be a Name. It's only when dropping that it's an ObjectName to be able to re-use most of the existing drop statement parsing. Long term best way to go would be break it out into its own special case of the drop statement instead of re-using the way it's done so far where all drop statements drop an ObjectName.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants