-
Notifications
You must be signed in to change notification settings - Fork 9
ddl2cpp: Cleanup part 4.2 #78
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
base: main
Are you sure you want to change the base?
Conversation
…es use snake_case, class names use CamelCase, private class members are prefixed with an underscore, constant names use SNAKE_CASE.
…ase to snake_case in order to improve PEP 8 compliance.
1f429fd
to
f957739
Compare
IIUC, the rename of Can you add a line to |
f957739
to
801fabc
Compare
OK, I added the following two lines to
There are also :
|
Thanks! Error code changes might be worth documenting. |
On a side note - the custom types file should probably be documented better (which is not that difficult to do since it currently has zero documentation :-)
The first column contains the base type which should be in |
OK, I'll add a line for the error code changes. |
3008f26
to
ee37126
Compare
I changed the PR a bit so that |
…id. If not then display a meaningful error message and exit with a specific error code.
…ase names for the base types. This provides compatibility with the old behavior where only CamelCase names were accepted.
ee37126
to
e777f31
Compare
I just pushed a small cosmetic change. It seems that originally somehow I was mistaken and thought that we keep the list of builtin SQL types in uppercase while in fact we keep them in lowercase. So I removed the uppercasing of custom types and left them lowercased as it was originally. Not that it really matters since the DDL parser makes all keyword comparisons case-insensitive. BTW I just noticed one discrepancy: we keep the list of builtin types in lowecase, but the list of auto-keywords is in uppercase. I won't be fixing that discrepancy in the current PR, since I don't want to add too much noise to the PR. |
e777f31
to
809be3d
Compare
AppVeyor timed out so I did a dummy update just to run AppVeyor again. |
This PR contains the last (for now) set of ddl2cpp cleanups. It makes the following changes:
snake_case
CamelCase
SNAKE_CASE
.snake_case
methods and variables for their module and classes and have deprecated the oldCamelCase
methods and variables. ddl2cpp relies on at least one feature in pyparsing 3.0.0 (pyparsing.Located
), which means that it requires at least pyparsing 3.0.0 to run, so we can safely switch to their new API. Also if I remember correctly the pyparsing developers said that sooner or later they will start emitting deprecation warnings, so we would have to make the switch anyway.CamelCase
tosnake_case
too. Most of the dictionary keys are also used as object attribute names, so we had to make this change too to be PEP 8-compliant.snake_case
names, e.g.integral
,floating_point
,boolean
,date_time
, etc. This change is mostly in order to make the base type names identical to the data_type names in sqlpp23, i.e.sqlpp::integral
,sqlpp::floating_point
, etc. However for compatibility purposes, the oldCamelCase
names for the base types are recognized too, e.g.Integral
,FloatingPoint
,Boolean
,DateTime
, etc.--path-to-datatype-file
has been renamed to--path-to-custom-types
. This is pretty much the only really breaking change in this PR. The code and output messages used a bunch of different names for the custom types, e.g. "custom types", "data types", "extended types", which (IMHO) was really confusing to the user. So I chose "custom types" as the (IMHO) most meaningful name and changed all the messages and code to use "custom types" when referring to the user-defined custom types. I also renamed the command-line option the reflect the unified name. I think that not too many people use the old argument name (--path-to-datatype-file
), because it only appeared recently, so it shouldn't cause too much problems to the users. If the option name change is too breaking, I can add the old option name as an alias. Or even revert to the old name. But IMHO it is worth keeping the new option name, since it better reflects what the option does.I did test the new PR and also fixed the tests (both the internal ddl2cpp self-tests and the CMake ones), so hopefully there won't be any breakage this time.