sqlalchemy-seerdb 0.2.0__tar.gz → 0.2.2__tar.gz

{sqlalchemy_seerdb-0.2.0/sqlalchemy_seerdb.egg-info → sqlalchemy_seerdb-0.2.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sqlalchemy-seerdb
-Version: 0.2.0
+Version: 0.2.2
 Summary: SQLAlchemy dialect for the seerdb driver
 Author-email: Peter Lemenkov <lemenkov@gmail.com>
 License-Expression: MIT
@@ -93,16 +93,33 @@ builds tables there.
 
 The test account cannot create it (`ORA-01031`), so run this as a DBA once:
 
+```
+python test/prepare_test_schema.py --host localhost --service XE \
+    --dba-password <SYSTEM password> --test-user <your test user>
+```
+
+It is safe to rerun: each statement is attempted on its own and one that has
+already been applied is reported and skipped. What it runs, for a DBA who would
+rather type it:
+
 ```sql
+-- the test account's own tables must live in USERS: the Oracle dialect hides
+-- SYSTEM-tablespace tables from reflection, and the suite then never empties
+-- them between tests (rows "survive", ORA-00001)
+ALTER USER <your test user> DEFAULT TABLESPACE USERS;
+ALTER USER <your test user> QUOTA UNLIMITED ON USERS;
+
 CREATE USER test_schema IDENTIFIED BY test_schema;
 GRANT CREATE SESSION TO test_schema;
-ALTER USER test_schema QUOTA UNLIMITED ON USERS;
+ALTER USER test_schema DEFAULT TABLESPACE USERS;
+GRANT UNLIMITED TABLESPACE TO test_schema;
 
--- so the test account can build and drop the fixtures inside that schema
+-- so the test account can build and drop the fixtures inside that schema;
+-- SELECT ANY SEQUENCE keeps sequences in test_schema visible to reflection
 GRANT CREATE ANY TABLE, DROP ANY TABLE, SELECT ANY TABLE, INSERT ANY TABLE,
       UPDATE ANY TABLE, DELETE ANY TABLE, CREATE ANY INDEX, DROP ANY INDEX,
       CREATE ANY VIEW, DROP ANY VIEW, CREATE ANY SEQUENCE, DROP ANY SEQUENCE,
-      COMMENT ANY TABLE, ANALYZE ANY TO <your test user>;
+      SELECT ANY SEQUENCE, COMMENT ANY TABLE, ANALYZE ANY TO <your test user>;
 ```
 
 Those `ANY` privileges are broad. They are fine on a throwaway test instance —

{sqlalchemy_seerdb-0.2.0 → sqlalchemy_seerdb-0.2.2}/README.md

@@ -71,16 +71,33 @@ builds tables there.
 
 The test account cannot create it (`ORA-01031`), so run this as a DBA once:
 
+```
+python test/prepare_test_schema.py --host localhost --service XE \
+    --dba-password <SYSTEM password> --test-user <your test user>
+```
+
+It is safe to rerun: each statement is attempted on its own and one that has
+already been applied is reported and skipped. What it runs, for a DBA who would
+rather type it:
+
 ```sql
+-- the test account's own tables must live in USERS: the Oracle dialect hides
+-- SYSTEM-tablespace tables from reflection, and the suite then never empties
+-- them between tests (rows "survive", ORA-00001)
+ALTER USER <your test user> DEFAULT TABLESPACE USERS;
+ALTER USER <your test user> QUOTA UNLIMITED ON USERS;
+
 CREATE USER test_schema IDENTIFIED BY test_schema;
 GRANT CREATE SESSION TO test_schema;
-ALTER USER test_schema QUOTA UNLIMITED ON USERS;
+ALTER USER test_schema DEFAULT TABLESPACE USERS;
+GRANT UNLIMITED TABLESPACE TO test_schema;
 
--- so the test account can build and drop the fixtures inside that schema
+-- so the test account can build and drop the fixtures inside that schema;
+-- SELECT ANY SEQUENCE keeps sequences in test_schema visible to reflection
 GRANT CREATE ANY TABLE, DROP ANY TABLE, SELECT ANY TABLE, INSERT ANY TABLE,
       UPDATE ANY TABLE, DELETE ANY TABLE, CREATE ANY INDEX, DROP ANY INDEX,
       CREATE ANY VIEW, DROP ANY VIEW, CREATE ANY SEQUENCE, DROP ANY SEQUENCE,
-      COMMENT ANY TABLE, ANALYZE ANY TO <your test user>;
+      SELECT ANY SEQUENCE, COMMENT ANY TABLE, ANALYZE ANY TO <your test user>;
 ```
 
 Those `ANY` privileges are broad. They are fine on a throwaway test instance —

{sqlalchemy_seerdb-0.2.0 → sqlalchemy_seerdb-0.2.2}/pyproject.toml

@@ -7,7 +7,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "sqlalchemy-seerdb"
-version = "0.2.0"
+version = "0.2.2"
 description = "SQLAlchemy dialect for the seerdb driver"
 readme = "README.md"
 license = "MIT"

{sqlalchemy_seerdb-0.2.0 → sqlalchemy_seerdb-0.2.2}/sqlalchemy_seerdb/__init__.py

@@ -19,4 +19,4 @@ from sqlalchemy_seerdb.seerdb import SeerdbDialect
 
 __all__ = ['SeerdbDialect', '__version__']
 
-__version__ = '0.2.0'
+__version__ = '0.2.2'

{sqlalchemy_seerdb-0.2.0 → sqlalchemy_seerdb-0.2.2}/sqlalchemy_seerdb/seerdb.py

@@ -32,7 +32,7 @@ from sqlalchemy.dialects.oracle.base import (
     OracleDialect,
     OracleExecutionContext,
 )
-from sqlalchemy.dialects.oracle.types import _OracleDate
+from sqlalchemy.dialects.oracle.types import _OracleBoolean, _OracleDate
 from sqlalchemy.engine import cursor as _cursor
 from sqlalchemy.engine import interfaces
 
@@ -72,6 +72,25 @@ class _SeerdbDate(_OracleDate):
         return process
 
 
+class _SeerdbBoolean(_OracleBoolean):
+    """A `Boolean` column read back as a `bool`.
+
+    Before 23ai there is no BOOLEAN type, so the column is a NUMBER and the
+    driver reads 1 or 0 back as a number. From SQLAlchemy 2.1 the generic
+    dialect leaves the conversion to an output type handler that only the
+    drivers it ships with install, so here it is taken as it is for `Date`. A
+    native BOOLEAN already arrives as a `bool` and passes through.
+    """
+
+    def result_processor(self, dialect, coltype):
+        def process(value):
+            if value is None or isinstance(value, bool):
+                return value
+            return bool(value)
+
+        return process
+
+
 class SeerdbExecutionContext(OracleExecutionContext):
     """Turns this backend's RETURNING into the rows SQLAlchemy expects.
 
@@ -238,6 +257,23 @@ class SeerdbCompiler(OracleCompiler):
         return super().bindparam_string(name, **kw)
 
 
+def _driver_has_fetch_lobs() -> bool:
+    """Whether the installed driver understands ``fetch_lobs``.
+
+    It arrived in seerdb 3.0 together with the LOB object; passing it to an
+    older driver is a TypeError, and this dialect supports both."""
+    import inspect
+
+    try:
+        params = inspect.signature(seerdb.OracleConnect.__init__).parameters
+    except (AttributeError, TypeError, ValueError):
+        return False
+    return 'fetch_lobs' in params
+
+
+_DRIVER_HAS_FETCH_LOBS = _driver_has_fetch_lobs()
+
+
 class SeerdbDialect(OracleDialect):
     """SQLAlchemy dialect driving the seerdb DBAPI."""
 
@@ -271,8 +307,13 @@ class SeerdbDialect(OracleDialect):
     # no processor either way, so a Float column came back holding a Decimal.
     supports_native_decimal = True
 
-    # As the base dialect's, plus the date narrowing above.
-    colspecs: ClassVar[dict] = {**_oracle_base.colspecs, sqltypes.Date: _SeerdbDate}
+    # As the base dialect's, plus the date narrowing and the boolean
+    # conversion above.
+    colspecs: ClassVar[dict] = {
+        **_oracle_base.colspecs,
+        sqltypes.Date: _SeerdbDate,
+        sqltypes.Boolean: _SeerdbBoolean,
+    }
 
     # No SQL is generated differently from the base dialect, so cached
     # statements stay valid.
@@ -347,6 +388,17 @@ class SeerdbDialect(OracleDialect):
         # DBAPI contract SQLAlchemy builds on is autocommit off, so that is the
         # default here; ``?autocommit=true`` in the URL still turns it on.
         options['autocommit'] = False
+        # SQLAlchemy's type machinery expects a CLOB / BLOB column to arrive as
+        # str / bytes -- its Text and LargeBinary result processors, and every
+        # comparison the compliance suite makes, are written against values.
+        # seerdb 3.0 returns a LOB OBJECT by default instead (matching
+        # python-oracledb), so ask for the values this dialect is built on.
+        #
+        # Feature-detected rather than pinned: the same dialect still has to
+        # work against a driver that predates the option, and its floor cannot
+        # be raised to a release that is not published yet.
+        if _DRIVER_HAS_FETCH_LOBS:
+            options['fetch_lobs'] = False
         for key, value in url.query.items():
             # A repeated key arrives as a tuple; the driver takes one value.
             options[key] = _coerce(

{sqlalchemy_seerdb-0.2.0 → sqlalchemy_seerdb-0.2.2/sqlalchemy_seerdb.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sqlalchemy-seerdb
-Version: 0.2.0
+Version: 0.2.2
 Summary: SQLAlchemy dialect for the seerdb driver
 Author-email: Peter Lemenkov <lemenkov@gmail.com>
 License-Expression: MIT
@@ -93,16 +93,33 @@ builds tables there.
 
 The test account cannot create it (`ORA-01031`), so run this as a DBA once:
 
+```
+python test/prepare_test_schema.py --host localhost --service XE \
+    --dba-password <SYSTEM password> --test-user <your test user>
+```
+
+It is safe to rerun: each statement is attempted on its own and one that has
+already been applied is reported and skipped. What it runs, for a DBA who would
+rather type it:
+
 ```sql
+-- the test account's own tables must live in USERS: the Oracle dialect hides
+-- SYSTEM-tablespace tables from reflection, and the suite then never empties
+-- them between tests (rows "survive", ORA-00001)
+ALTER USER <your test user> DEFAULT TABLESPACE USERS;
+ALTER USER <your test user> QUOTA UNLIMITED ON USERS;
+
 CREATE USER test_schema IDENTIFIED BY test_schema;
 GRANT CREATE SESSION TO test_schema;
-ALTER USER test_schema QUOTA UNLIMITED ON USERS;
+ALTER USER test_schema DEFAULT TABLESPACE USERS;
+GRANT UNLIMITED TABLESPACE TO test_schema;
 
--- so the test account can build and drop the fixtures inside that schema
+-- so the test account can build and drop the fixtures inside that schema;
+-- SELECT ANY SEQUENCE keeps sequences in test_schema visible to reflection
 GRANT CREATE ANY TABLE, DROP ANY TABLE, SELECT ANY TABLE, INSERT ANY TABLE,
       UPDATE ANY TABLE, DELETE ANY TABLE, CREATE ANY INDEX, DROP ANY INDEX,
       CREATE ANY VIEW, DROP ANY VIEW, CREATE ANY SEQUENCE, DROP ANY SEQUENCE,
-      COMMENT ANY TABLE, ANALYZE ANY TO <your test user>;
+      SELECT ANY SEQUENCE, COMMENT ANY TABLE, ANALYZE ANY TO <your test user>;
 ```
 
 Those `ANY` privileges are broad. They are fine on a throwaway test instance —

{sqlalchemy_seerdb-0.2.0 → sqlalchemy_seerdb-0.2.2}/sqlalchemy_seerdb.egg-info/SOURCES.txt

@@ -11,6 +11,7 @@ sqlalchemy_seerdb.egg-info/dependency_links.txt
 sqlalchemy_seerdb.egg-info/entry_points.txt
 sqlalchemy_seerdb.egg-info/requires.txt
 sqlalchemy_seerdb.egg-info/top_level.txt
+test/test_boolean.py
 test/test_connect_args.py
 test/test_suite.py
 test/test_version.py

sqlalchemy_seerdb-0.2.2/test/test_boolean.py

@@ -0,0 +1,32 @@
+# SPDX-FileCopyrightText: 2026 Peter Lemenkov <lemenkov@gmail.com>
+# SPDX-License-Identifier: MIT
+
+"""A Boolean column comes back as a bool whatever the driver returns."""
+
+import unittest
+
+from sqlalchemy import types as sqltypes
+
+from sqlalchemy_seerdb.seerdb import SeerdbDialect, _SeerdbBoolean
+
+
+class TestBoolean(unittest.TestCase):
+    def setUp(self):
+        self.process = _SeerdbBoolean().result_processor(SeerdbDialect(), None)
+
+    def test_a_number_becomes_a_bool(self):
+        # Before 23ai the column is a NUMBER, and the driver reads 1 / 0.
+        self.assertIs(self.process(1), True)
+        self.assertIs(self.process(0), False)
+
+    def test_a_native_bool_and_a_null_pass_through(self):
+        self.assertIs(self.process(True), True)
+        self.assertIs(self.process(False), False)
+        self.assertIsNone(self.process(None))
+
+    def test_the_dialect_uses_it_for_boolean(self):
+        self.assertIs(SeerdbDialect.colspecs[sqltypes.Boolean], _SeerdbBoolean)
+
+
+if __name__ == '__main__':
+    unittest.main()