-
Notifications
You must be signed in to change notification settings - Fork 216
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
Deprecate UseJsPropertyNames and ECSqlStatement (which defaults to UseJsPropertyNames) #7315
base: master
Are you sure you want to change the base?
Conversation
@Mergifyio backport release/4.10.x |
🟠 Waiting for conditions to match
|
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.
lets include a comment about this in NextVersion.md.
That can be done in the bp pr to release/4.10.x branch
…eprecate-ecsql-stuff
https://github.com/Mergifyio backport release/4.11.x |
🟠 Waiting for conditions to match
|
doc changes can go into release/4.11.x branch |
…eprecate-ecsql-stuff
…eprecate-ecsql-stuff
I cannot approve because I created the PR, but it's looking good to me. The only thing I can see missing is a note in next version md covering changes |
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.
does it make sense for the example code snippets that get pulled into the docs site use the new api instead of suppressing the deprecation warnings?
Co-authored-by: Arun George <[email protected]>
Co-authored-by: Arun George <[email protected]>
Update deprecated in version to 4.11 Co-authored-by: Arun George <[email protected]>
@rschili would you be able to review since @ColinKerr and @khanaffan both worked on the pr? |
stmt.bindString(1, changeSetId); | ||
if (DbResult.BE_SQLITE_ROW === stmt.step()) | ||
return stmt.getValue(0).getId(); | ||
// eslint-disable-next-line @typescript-eslint/no-deprecated |
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.
Why ignore deprecation warnings instead of updating to use preferred replacement APIs? (Here and lots of other places).
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 have the same concerns, but the blast radius here is quite a lot, so I'm ok if we are temporarily suppressing the deprecation warnings internally. But I would hope and require we use the new api in our documentation with this pr, and have examples (in example-code snippets)
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.
As I understand, we do not offer a sync replacement for the deprecated API, so to switch to ConcurrentQuery in a clean way we may have to make the caller methods async as well. Which would increase the blast radius even more.
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.
Is there some reason to believe the people consuming the deprecated APIs will not experience similar friction in attempting to address the new deprecation warnings in their own code? It sounds like our replacement APIs are insufficient, which suggests deprecation may be premature.
I have updated the nextversion.md |
this should go in the bp to 4.11 not on master |
All changes should be committed to the master branch first, as it serves as our source of truth. Deprecating a feature in version 4.x implies it is also deprecated in version 5.x. Currently, we do not have a timeline for updating the code in iTwin.js 5.x to transition from ECSQL statements to ECSQLReader." |
Agreed, however the |
Will do first thing tomorrow. |
I updated Presentation code to use recommended APIs instead of deprecated ones. @saskliutas please review. |
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.
Please review my concerns about caller methods who continue to use Statement. Is there a clean sync replacement for statement or do we have to make all callers async once we switch to ConcurrentQuery? If so, we should deprecate the remaining callers as well and provide async replacements...
@@ -1229,6 +1243,7 @@ export abstract class IModelDb extends IModel { | |||
*/ | |||
public querySchemaVersion(schemaName: string): string | undefined { | |||
const sql = `SELECT VersionMajor,VersionWrite,VersionMinor FROM ECDbMeta.ECSchemaDef WHERE Name=:schemaName LIMIT 1`; | |||
// eslint-disable-next-line @typescript-eslint/no-deprecated |
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 believe we need to deprecate this method as well. We cannot rewrite it to async without breaking its signature. Once we remove statement this will have to become async
@@ -1613,6 +1628,7 @@ export namespace IModelDb { | |||
*/ | |||
public queryLastModifiedTime(modelId: Id64String): string { | |||
const sql = `SELECT LastMod FROM ${Model.classFullName} WHERE ECInstanceId=:modelId`; | |||
// eslint-disable-next-line @typescript-eslint/no-deprecated |
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.
This method probably needs to be turned async/deprecated as well
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.
There are more occurrences along the rest of the file
stmt.bindString(1, changeSetId); | ||
if (DbResult.BE_SQLITE_ROW === stmt.step()) | ||
return stmt.getValue(0).getId(); | ||
// eslint-disable-next-line @typescript-eslint/no-deprecated |
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.
As I understand, we do not offer a sync replacement for the deprecated API, so to switch to ConcurrentQuery in a clean way we may have to make the caller methods async as well. Which would increase the blast radius even more.
No description provided.