-
Notifications
You must be signed in to change notification settings - Fork 601
Enable dialect specific behaviours in the parser #254
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
Enable dialect specific behaviours in the parser #254
Conversation
Pull Request Test Coverage Report for Build 195813271
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
To give some context, this continues from #241 (comment) and combines an earlier draft c67d667 with the ability to branch on the dialect identity. It was split from #244.
src/dialect/mod.rs
Outdated
/// The name of the dialect | ||
fn dialect_name(&self) -> &'static str; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not fond of using strings for checking for a particular dialect in the parser code, especially because a typo in the dialect name (as the one in this PR) can easily go unnoticed. The best I can come up with is:
pub trait Dialect: Debug + Any {
...
impl dyn Dialect {
#[inline]
pub fn is<T: Dialect>(&self) -> bool { // borrowed from `Any` implementation
TypeId::of::<T>() == self.type_id()
}
}
...
if self.dialect.is::<MsSqlDialect>() {
@Dandandan or @maxcountryman do you have any thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep- the static type is much better , i wasn't aware of the ANY trait in RUST .
I tried to take the same approach but with macro's WDYT ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since GitHub thinks this branch of discussion is "outdated', I continued below.
1a56d86
to
e8b1dd5
Compare
e8b1dd5
to
742c50e
Compare
Continuing from above
I thought macros could be layered on top of If we use a macro for branching, we could make it accept a list of dialects, e.g.
|
742c50e
to
cae5d37
Compare
Ok , updated the commit according to the suggestion . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ready to merge this, but I'll give the rest of the team a few days to react. I don't think your other PRs have to wait for this one to be merged?
@andygrove thought I ought to mention you explicitly here, given your previous interest in this topic. Although I understand you don't have much time for this these days. (If you're interested in diving in, the context is in my previous comment.)
src/dialect/mod.rs
Outdated
/// Determine if the specified dialect matched to | ||
/// the parsed dialect , used for dialect spefic behaviour |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think an example will be easier to understand here:
/// `dialect_of!(parser is SQLiteDialect | GenericDialect)` evaluates
/// to `true` iff `parser.dialect` is one of the `Dialect`s specified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed
cae5d37
to
1bed7b0
Compare
1bed7b0
to
c87f916
Compare
Hey @eyalleshem, sorry for the delay. I wanted to merge this, but found that you added unrelated functionality in the most recent force-push. Could you reset this PR back to 1bed7b0 ? It's not available to me or my git-fu is too weak for this. |
Hi @nickolay, by mistake i added some functionally to this PR before 6 days , but it's removed immediately - the current content of the current commit in the PR , is same as 1bed7b0, I think the commit hash's are different because the PR rebased On the main branch , while 1bed7b0 not . sorry for the mess.. |
You're right, I got confused. Merged, thanks! |
[nickolay: added the following from the final commit message]
Change
Parser { ... }
to store the dialect used:Parser<'a> { ... dialect: &'a dyn Dialect }
Thanks to @c7hm4r for the initial version of this submitted as
part of Add support for "on delete cascade" column option #170
Introduce
dialect_of!(parser is SQLiteDialect | GenericDialect)
helperto branch on the dialect's type
Use the new functionality to make
AUTO_INCREMENT
andAUTOINCREMENT
parsing dialect-dependent.