Node: Document Database Service#1667
Conversation
|
|
||
|
|
||
|
|
||
| ### <span style="color:grey">srv</span>.begin <i> () → this </i> {#db-begin } |
There was a problem hiding this comment.
I'm not sure, but maybe we should adapt this "new style" as shown here:
|
|
||
| ### <span style="color:grey">srv</span>.run <i> () → this </i> {#db-run } | ||
|
|
||
| Runs the provided `cds.ql.Query` using the current DatabaseService. |
There was a problem hiding this comment.
what about plain queries? we should mention that they are supported as fallback option, but should always use "for security reasons" prepared statement syntax, i.e., run('INSERT into T values (?,?)', 1, 'alice')
Adds a "SAP HANA - Known Limitations" section to node.js/databases.md, collected for BLI cap/cdsnode#2725. The section is grouped: - General (driver-independent) - hdb driver - @sap/hana-client driver Covers virtual elements in expressions, BLOB defaults, date/time ranges, draft + LargeBinary handling (with move_media_data_in_db and binary_draft_compat flags), binary filter limitations on hdb, HanaLobStream / for-await on hana-client, and related driver quirks.
- Move timestamp precision from hdb-only to General, since the runtime workaround applies to every HANA driver (originally reported on hdb, BLI capire#2368). - Move "any() over unmanaged-association navigation" out of General into a new @cap-js/hana driver subsection (hdb supports it). - Clarify that the UNION limitation applies to all databases.
The source comment (cds/tests/.../timestamp.test.js:26) explicitly names hdb. The runtime line `timestamp.slice(0, 23) + 'Z'` is a test-side simplification, not evidence the limitation applies to other HANA drivers. Per the classification rule "comment names a driver -> not General", this belongs under hdb.
| #### Date/time range and formatting | ||
|
|
||
| - `DATE`, `SECONDDATE`, and `TIMESTAMP` reject years ≤ 0 and years ≥ 10000. | ||
| - The upper bound is `9999-12-31 23:59:59` — `24:00:00` is **not** accepted (it is on some other databases). | ||
| - Truncated forms are not auto-expanded; date components must be fully specified when a time is included. |
There was a problem hiding this comment.
Yes that is the case, but I would definitely not see this as a limitation that WE should document. This follows the ISO standards...
| #### UPDATE with streams does not report affected rows | ||
|
|
||
| When an `UPDATE` includes streamed parameters (LOBs), `@sap/hana-client` returns `0` even if rows were modified. The runtime treats `streams.length && changes === 0` as success. As a side effect, ETag/affected-row checks during streaming UPDATEs are unreliable. |
There was a problem hiding this comment.
This is a valid issue, but nothing like how this is describing it. It doesn't apply to UPDATE. It actually applies to INSERT queries, because we stream our rows. While the driver returns the number of affected rows before it is possible to upload the source of the entries. Which means that there is no way for HANA to determine how many rows are going to be uploaded afterwards.
Why this does not apply to UPDATE is that there is no way to use a LOB in the WHERE condition of the query, because the only check that is allowed to be done on a LOB is IS NULL which will be send along already if the value is null instead of Readable.
4 participants
No description provided.