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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sqlalchemy-seerdb
-Version: 0.2.0
+Version: 0.2.1
 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.1}/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.1}/pyproject.toml

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

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

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

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

@@ -238,6 +238,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."""
 
@@ -347,6 +364,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.1/sqlalchemy_seerdb.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sqlalchemy-seerdb
-Version: 0.2.0
+Version: 0.2.1
 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 —