Bump version: 4.0.0 → 4.1.0 #119
Conversation
|
Warning Rate limit exceeded@amunra has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 5 minutes and 3 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (10)
WalkthroughVersion bumped 4.0.0 → 4.1.0 across packaging and runtime metadata; documentation and examples added clarifying DECIMAL column ingestion, Arrow/Pandas decimal support, protocol_version 3, and timestamp precision. No public API signatures changed. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
examples/decimal.py (1)
1-33: Decimal example is correct; consider briefly calling out why explicit table creation mattersThe example correctly:
- Pre-creates
financial_datawithDECIMAL(18, 6)/DECIMAL(12, 4).- Uses matching
Decimalliterals andTimestampNanos.now()in bothrow()anddataframe()calls.Optional improvement: add a short note that explicitly creating the table lets users control DECIMAL precision/scale, whereas letting QuestDB auto-create DECIMAL columns will use the server’s defaults (as seen in earlier system tests). Based on learnings, this would help set expectations for users comparing this example with auto-created tables.
setup.py (1)
176-176: setup.py version updated to 4.1.0; consider later aligning Python version constraintsThe package version now matches the 4.1.0 release and other metadata files, which is good.
Separately (not new in this PR),
python_requires='>=3.8'here differs fromrequires-python = ">=3.9"inpyproject.toml. It may be worth aligning those in a follow‑up to avoid confusing installers.docs/changelog.rst (1)
1-12: Changelog wrapper is solid;:start-line:is slightly brittleThis Sphinx wrapper cleanly exposes the project changelog with an anchor and local contents, which is useful.
Minor suggestion: using
:start-line: 7tightly couples this include to the current structure ofCHANGELOG.rst. If that file gains or loses header lines, the slice may no longer start where you expect. If you foresee frequent edits there, consider dropping:start-line:and instead structuringCHANGELOG.rstso the included section is naturally what you want.CHANGELOG.rst (2)
38-45: Clarify server-side defaults for DECIMAL precision and scale.The important note correctly mentions manual creation requirement, but it would help users to understand the server's default behavior. Based on learnings from prior QuestDB ingestion testing, when the server auto-creates DECIMAL columns, it uses a default precision of 18 and scale of 3.
Consider adding a brief note clarifying this, especially for users working with dataframes or PyArrow types where they may not have explicit control over column creation.
93-110: PyArrow decimal example may mislead users about server-side scale.The example declares
pa.decimal128(18, 2)but based on the retrieval learnings, QuestDB's server applies its own defaults. When data is ingested, the server may normalize the scale regardless of the client-side PyArrow type declaration.Add a clarifying note explaining that while the client specifies the PyArrow type as
decimal128(18, 2), the server-side column may store and return values with different precision/scale depending on the table definition and server defaults (e.g., scale may be 3 rather than 2).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
.bumpversion.toml(1 hunks)CHANGELOG.rst(1 hunks)README.rst(1 hunks)docs/changelog.rst(1 hunks)docs/conf.py(1 hunks)docs/conf.rst(2 hunks)docs/examples.rst(1 hunks)docs/index.rst(1 hunks)docs/sender.rst(1 hunks)docs/troubleshooting.rst(1 hunks)examples/decimal.py(1 hunks)examples/decimal_arrow.py(1 hunks)pyproject.toml(1 hunks)setup.py(1 hunks)src/questdb/__init__.py(1 hunks)src/questdb/ingress.pyi(1 hunks)src/questdb/ingress.pyx(2 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: RaphDal
Repo: questdb/py-questdb-client PR: 114
File: test/system_test.py:317-324
Timestamp: 2025-11-07T15:46:43.284Z
Learning: In QuestDB, when decimal values are ingested, the server creates DECIMAL columns with a default precision of 18 and scale of 3, regardless of the scale declared in the client-side data type (e.g., pyarrow.decimal128(18, 2)). Values are stored and returned with 3 decimal places.
📚 Learning: 2025-11-07T15:46:43.284Z
Learnt from: RaphDal
Repo: questdb/py-questdb-client PR: 114
File: test/system_test.py:317-324
Timestamp: 2025-11-07T15:46:43.284Z
Learning: In QuestDB, when decimal values are ingested, the server creates DECIMAL columns with a default precision of 18 and scale of 3, regardless of the scale declared in the client-side data type (e.g., pyarrow.decimal128(18, 2)). Values are stored and returned with 3 decimal places.
Applied to files:
CHANGELOG.rstdocs/sender.rstdocs/troubleshooting.rstdocs/examples.rstexamples/decimal.pyexamples/decimal_arrow.py
📚 Learning: 2025-10-22T07:31:37.016Z
Learnt from: RaphDal
Repo: questdb/py-questdb-client PR: 114
File: src/questdb/ingress.pyx:192-195
Timestamp: 2025-10-22T07:31:37.016Z
Learning: In src/questdb/ingress.pyx, the IngressErrorCode.BadDataFrame enum member is Python-internal only and does not map to any C error code from the underlying library. It is defined as `<int>line_sender_error_invalid_decimal + 1` and should not be added to the c_err_code_to_py function, which only handles C-to-Python error code translation.
Applied to files:
docs/troubleshooting.rstsrc/questdb/ingress.pyx
🧬 Code graph analysis (1)
examples/decimal_arrow.py (1)
src/questdb/ingress.pyi (3)
Sender(821-1153)TimestampNanos(131-179)from_conf(857-891)
🔇 Additional comments (17)
pyproject.toml (1)
5-5: Project version bump to 4.1.0 looks correctThe metadata version aligns with the rest of the PR’s stated 4.1.0 release; no issues from this change alone.
src/questdb/ingress.pyi (1)
549-549: Doctype update forsymbolsis clear and consistentUsing
list[str]/list[int]here matches the argument description above and modern typing style; no further changes needed.README.rst (1)
21-21: README version text updated correctlyThe “latest version” line now reflects 4.1.0 and stays consistent with the package metadata and changelog.
docs/index.rst (1)
12-12: Reduced toctree maxdepth to 1 is fineLimiting the index toctree to a single level simplifies the sidebar/navigation without impacting the listed sections; looks intentional and safe.
src/questdb/__init__.py (1)
1-1: Version 4.1.0 correctly set and synced across all configuration filesThe
__version__insrc/questdb/__init__.pyis properly synchronized withpyproject.tomlandsetup.py. A search for any lingering 4.0.0 references found only a historical changelog entry (expected), confirming no stale version strings remain in active code or documentation.src/questdb/ingress.pyx (2)
107-107: LGTM! Version bump is correct.The version update from '4.0.0' to '4.1.0' is consistent with the PR objectives and aligns with version updates across all other project files.
1316-1316: LGTM! Type annotation improvement.The updated type annotation syntax
list[str] or list[int]is clearer and uses modern Python type hint style compared to the previous "list of str or list of int" prose format.docs/conf.py (1)
31-31: LGTM! Documentation version updated.The Sphinx documentation version is correctly updated to match the package version bump.
docs/conf.rst (1)
242-254: LGTM! Clear protocol version 3 documentation.The new section clearly documents protocol version 3 requirements and capabilities, including:
- Server version requirement (QuestDB 9.2.0+)
- DECIMAL type support
- Inclusion of all version 2 features
The documentation is well-structured and consistent with the existing format.
examples/decimal_arrow.py (1)
1-27: LGTM! Well-documented decimal ingestion example.The example clearly demonstrates:
- Pre-creation requirement with SQL CREATE TABLE statement
- Using PyArrow decimal types with pandas
- Proper symbol and timestamp handling
The example aligns with the documentation updates and provides a practical reference for users needing decimal precision.
Note: Based on learnings, the QuestDB server stores decimal values with its own precision/scale (default 18,3), regardless of the client-side type declaration. Users should ensure their table definitions match their data requirements.
.bumpversion.toml (1)
2-2: LGTM! Version configuration updated.The bumpversion configuration correctly reflects the new version 4.1.0.
docs/troubleshooting.rst (1)
46-81: LGTM! Comprehensive decimal troubleshooting guide.The new troubleshooting section effectively addresses common decimal ingestion issues:
- Clear explanation of pre-creation requirement
- Distinguishes protocol version handling between HTTP/HTTPS and TCP/TCPS
- Provides concrete examples and links to official documentation
This will help users avoid common pitfalls when working with decimal types.
docs/examples.rst (1)
114-152: LGTM! Comprehensive decimal types documentation.The new section provides:
- Clear server and protocol version requirements
- SQL table creation example
- Python examples using both
decimal.Decimaland PyArrow types- Important notes about protocol version handling differences between HTTP/HTTPS and TCP/TCPS
- Helpful cross-references to troubleshooting and official documentation
This gives users a complete guide for working with decimal types.
docs/sender.rst (3)
150-202: LGTM! Thorough decimal columns documentation.The new section provides comprehensive coverage:
- Server version requirement (9.2.0+) and protocol version 3
- Pre-creation requirement with clear explanation
- Code examples for both
row()method anddataframe()method- Performance optimization using PyArrow decimal types
- Helpful cross-references to configuration and troubleshooting
This gives users complete guidance for decimal column ingestion.
203-231: LGTM! Improved timestamp documentation.The updated section clarifies:
- Support for both
TimestampMicrosandTimestampNanos- QuestDB storage formats (TIMESTAMP vs TIMESTAMP_NS)
- Microsecond and nanosecond precision handling
- Server version requirement for nanosecond support (9.1.0+)
- UTC representation and timezone handling
The documentation is clearer and more precise than before.
814-817: LGTM! Protocol auto-detection table updated.The updated table correctly documents that:
- ILP/HTTP supports protocol version auto-detection
- ILP/TCP requires explicit configuration
This clarifies an important difference between the two protocols for users.
CHANGELOG.rst (1)
11-136: Overall changelog content is well-structured and comprehensive.The 4.1.0 release notes clearly document the major features (decimal support, additional Arrow types, microsecond precision) and provide concrete code examples. The breaking change documentation is thorough, configuration requirements are explicit (protocol_version=3), and the important caveats about manual table creation are highlighted.
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/sender.rst (1)
143-148: Syntax error: Missing comma beforeat=parameter.The code example has a syntax error that will prevent it from running.
columns={ 'price': 2615.54, - 'amount': 0.00044} - at=datetime.datetime(2021, 1, 1, 12, 0, 0)) + 'amount': 0.00044}, + at=datetime.datetime(2021, 1, 1, 12, 0, 0))
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
docs/examples.rst(1 hunks)docs/sender.rst(1 hunks)docs/troubleshooting.rst(1 hunks)examples/decimal.py(1 hunks)examples/decimal_arrow.py(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- examples/decimal_arrow.py
- docs/examples.rst
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-07T15:46:43.284Z
Learnt from: RaphDal
Repo: questdb/py-questdb-client PR: 114
File: test/system_test.py:317-324
Timestamp: 2025-11-07T15:46:43.284Z
Learning: In QuestDB, when decimal values are ingested, the server creates DECIMAL columns with a default precision of 18 and scale of 3, regardless of the scale declared in the client-side data type (e.g., pyarrow.decimal128(18, 2)). Values are stored and returned with 3 decimal places.
Applied to files:
docs/troubleshooting.rstdocs/sender.rstexamples/decimal.py
📚 Learning: 2025-10-22T07:31:37.016Z
Learnt from: RaphDal
Repo: questdb/py-questdb-client PR: 114
File: src/questdb/ingress.pyx:192-195
Timestamp: 2025-10-22T07:31:37.016Z
Learning: In src/questdb/ingress.pyx, the IngressErrorCode.BadDataFrame enum member is Python-internal only and does not map to any C error code from the underlying library. It is defined as `<int>line_sender_error_invalid_decimal + 1` and should not be added to the c_err_code_to_py function, which only handles C-to-Python error code translation.
Applied to files:
docs/troubleshooting.rst
🧬 Code graph analysis (1)
examples/decimal.py (1)
src/questdb/ingress.pyi (3)
Sender(821-1153)TimestampNanos(131-179)from_conf(857-891)
🔇 Additional comments (6)
docs/troubleshooting.rst (4)
46-49: Documentation structure is well organized.The RST anchor and subsection formatting are correct. The placement under "Errors during flushing" is logical.
54-64: Verify documentation accuracy regarding DECIMAL auto-creation behavior.The documentation states DECIMAL columns "cannot be auto-created" and must be pre-created. However, the learnings from PR 114 indicate that when decimal values are ingested, QuestDB creates DECIMAL columns with default precision 18 and scale 3. Please clarify whether:
- DECIMAL auto-creation is actually prevented/blocked by the server, or
- The recommendation to pre-create is a best practice to avoid relying on server defaults (precision 18, scale 3)?
The SQL example at lines 58–64 is syntactically correct and well-formatted.
77-83: I'll verify the documentation link and ensure the precision/scale guidance is accurate. Let me start by checking the link validity and reviewing the full context of the documentation.
<function_calls>
#!/bin/bashCheck if the QuestDB DECIMAL documentation link is accessible
curl -I -s https://questdb.io/docs/reference/sql/datatypes/#decimal | head -5
</function_calls>
<function_calls>
#!/bin/bashRead the full troubleshooting.rst file to understand context around lines 77-83
fd troubleshooting.rst | head -1 | xargs cat -n | sed -n '70,90p'
</function_calls>
66-75: All protocol version and server version requirements are accurate.The documentation correctly states that decimal support requires protocol version 3 (QuestDB 9.2.0+), that HTTP/HTTPS auto-negotiate this version, and that TCP/TCPS requires explicit configuration. These claims are confirmed in the CHANGELOG and client code:
- CHANGELOG.rst line 26-27: "Sending decimals requires protocol version 3. When using HTTP, this protocol version is auto-negotiated."
- CHANGELOG.rst line 28: "For TCP connections, you must explicitly specify
protocol_version=3"- CHANGELOG.rst line 39: "This feature requires QuestDB server version 9.2.0 or higher."
- Web verification confirms QuestDB 9.2.0 adds native DECIMAL type with protocol v3 support.
examples/decimal.py (1)
1-33: LGTM!The example clearly demonstrates both
row()anddataframe()methods for DECIMAL data ingestion. The SQL schema comment properly documents the pre-creation requirement, and the Decimal values align with the specified precision and scale.docs/sender.rst (1)
209-237: Clear and comprehensive timestamp documentation.The updated section properly distinguishes between
TIMESTAMP(microseconds) andTIMESTAMP_NS(nanoseconds) column types, documents bothTimestampMicrosandTimestampNanosobjects, and correctly notes the QuestDB 9.1.0 requirement for nanosecond support.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
docs/sender.rst (2)
213-216: Correct URL domain and fix RST link syntax.Line 216 uses the inconsistent domain
questdb.comwhen other documentation links usequestdb.io. Additionally, the RST link appears incomplete—it's missing the closing underscore required for inline link syntax.Apply this diff:
-`partitioning <https://questdb.com/docs/concept/partitions/>`. +`partitioning <https://questdb.io/docs/concept/partitions/>`_.Note: Line 522 may have a similar issue and should be checked separately.
175-207: Resolve table name mismatch between SQL schema and code examples.The SQL schema comment at line 175 references table
financial_data, but the subsequentrow()anddataframe()calls use table'prices'(lines 184, 193). Users following this example will encounter errors if they create the table using the SQL comment but attempt to send data using the inconsistent table name in the code.Align both the comment and the code examples to use the same table name consistently—either update the SQL to
pricesor update the code calls tofinancial_data.Suggested fix (update comment to match code):
- # CREATE TABLE financial_data ( + # CREATE TABLE prices (Alternatively, update the code calls to match the comment:
sender.row( - 'prices', + 'financial_data', symbols={'symbol': 'BTC-USD'},
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
docs/examples.rst(1 hunks)docs/sender.rst(1 hunks)docs/troubleshooting.rst(1 hunks)examples/decimal.py(1 hunks)examples/decimal_arrow.py(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- docs/examples.rst
- examples/decimal_arrow.py
- docs/troubleshooting.rst
- examples/decimal.py
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-07T15:46:43.284Z
Learnt from: RaphDal
Repo: questdb/py-questdb-client PR: 114
File: test/system_test.py:317-324
Timestamp: 2025-11-07T15:46:43.284Z
Learning: In QuestDB, when decimal values are ingested, the server creates DECIMAL columns with a default precision of 18 and scale of 3, regardless of the scale declared in the client-side data type (e.g., pyarrow.decimal128(18, 2)). Values are stored and returned with 3 decimal places.
Applied to files:
docs/sender.rst
🔇 Additional comments (2)
docs/sender.rst (2)
150-169: Approve the Decimal Columns introduction and documentation structure.The new Decimal Columns section provides clear guidance on requirements (protocol version 3, table pre-creation) and points users to relevant resources. The introduction at lines 150–169 appropriately sets expectations and is well-organized.
221-237: Approve the timestamp documentation updates.The additions clarifying
TimestampMicrossupport (line 222), timestamp storage representation (lines 229–232), and version compatibility for nanosecond support (lines 234–236) enhance user understanding and align well with the 4.1.0 feature set.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
CHANGELOG.rst (1)
47-110: Decimal examples are clear and well-structured.The usage examples effectively demonstrate Python
Decimal, Pandas, and PyArrow approaches with proper SQL table pre-creation patterns. The important note about manual table creation and server version requirements is appropriately emphasized.However, based on learnings from the QuestDB integration tests, you may want to clarify the relationship between client-side precision/scale declarations and server behavior. When tables are created via SQL (as shown in these examples), the declared precision/scale are respected. But this context could benefit from a brief note for users working with existing tables or auto-created schemas.
Consider adding a brief note like:
.. note:: When sending decimals to an existing DECIMAL column, ensure the column's precision and scale match your data to avoid truncation or rounding errors. The server enforces the column's declared precision/scale, not the client-side type.This would help prevent confusion if users attempt to ingest data into pre-existing decimal columns with different scale characteristics.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
CHANGELOG.rst(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-07T15:46:43.284Z
Learnt from: RaphDal
Repo: questdb/py-questdb-client PR: 114
File: test/system_test.py:317-324
Timestamp: 2025-11-07T15:46:43.284Z
Learning: In QuestDB, when decimal values are ingested, the server creates DECIMAL columns with a default precision of 18 and scale of 3, regardless of the scale declared in the client-side data type (e.g., pyarrow.decimal128(18, 2)). Values are stored and returned with 3 decimal places.
Applied to files:
CHANGELOG.rst
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (15)
- GitHub Check: questdb.py-questdb-client (1) (cibuildwheel linux_arm64)
- GitHub Check: questdb.py-questdb-client (1) (cibuildwheel windows_x86_64)
- GitHub Check: questdb.py-questdb-client (1) (cibuildwheel windows_i686)
- GitHub Check: questdb.py-questdb-client (1) (cibuildwheel linux_x64_cpython_manylinux_x86_64)
- GitHub Check: questdb.py-questdb-client (1) (cibuildwheel start_linux_arm64_agent_aws)
- GitHub Check: questdb.py-questdb-client (1) (cibuildwheel linux_x64_pypy)
- GitHub Check: questdb.py-questdb-client (1) (cibuildwheel macos_x64)
- GitHub Check: questdb.py-questdb-client (1) (cibuildwheel linux_x64_cpython_musllinux)
- GitHub Check: questdb.py-questdb-client (Building and testing on windows-msvc-2019)
- GitHub Check: questdb.py-questdb-client (Building and testing on mac)
- GitHub Check: questdb.py-questdb-client (Building and testing on linux-qdb-master)
- GitHub Check: questdb.py-questdb-client (Building and testing on linux-old-pandas)
- GitHub Check: questdb.py-questdb-client (Building and testing on linux)
- GitHub Check: questdb.py-questdb-client (Building and testing TestsAgainstVariousNumpyVersion2x)
- GitHub Check: questdb.py-questdb-client (Building and testing TestsAgainstVariousNumpyVersion1x)
🔇 Additional comments (2)
CHANGELOG.rst (2)
112-136: Arrow types and microsecond precision sections are concise and accurate.The feature additions are clearly described with appropriate protocol version requirements noted. The bug fix entry properly acknowledges the alignment between type hints and runtime behavior for
Nonevalues.
8-46: Release header and introduction are well-formatted.The 4.1.0 section structure follows the existing changelog conventions, and the introductory descriptions clearly communicate feature scope and server requirements. Protocol version handling (HTTP auto-negotiation vs. TCP explicit configuration) is well-explained.
Bumping the version and updating the documentation and change log to match.
Summary by CodeRabbit
New Features
Documentation
Bug Fixes
Chores
✏️ Tip: You can customize this high-level summary in your review settings.