sql_fusion 1.2.1__tar.gz → 1.2.2__tar.gz

{sql_fusion-1.2.1 → sql_fusion-1.2.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: sql_fusion
-Version: 1.2.1
+Version: 1.2.2
 Summary: Python query builder with a focus on composability and reusability.
 Author: Mastermind-U
 Author-email: Mastermind-U <rex49513@gmail.com>
@@ -72,6 +72,22 @@ SQL Fusion is built for the middle ground:
 
 In short, the goal is to keep the ergonomics of a lightweight builder while still covering the parts of SQL that matter in real applications.
 
+### Why not SQLAlchemy ORM or Core?
+
+SQLAlchemy is an excellent tool, but it is also a much heavier and more universal system:
+
+- it brings a larger abstraction surface than this project needs
+- it is optimized for a broad ORM and Core ecosystem, not only for a small SQL builder
+- some connectors and databases still do not have first-class SQLAlchemy integrations, which can make adoption less straightforward in mixed environments
+
+SQLAlchemy Core is closer to SQL Fusion than the full ORM, but it still carries more machinery than this project is meant to expose:
+
+- it is part of a broader ecosystem with dialects, compilation layers, and extra conventions
+- it can feel more verbose when you only want a small chainable builder
+- some connectors and databases still do not have smooth SQLAlchemy Core support, so portability can depend on the backend
+
+SQL Fusion is intentionally narrower so it can stay lightweight, easy to embed, and practical for DB-API style backends without extra complexity.
+
 ## What You Get
 
 - `SELECT`, `INSERT`, `UPDATE`, and `DELETE` builders
@@ -409,9 +425,9 @@ query, params = select().from_(paid_orders).compile()
 
 SQL Fusion supports compound queries through three small wrapper classes:
 
-- `union(query1, query2, all=False, by_name=False)`
-- `intersect(q1, q2, all_=False)`
-- `except_(q1, q2, all_=False)`
+- `union(query1, query2, all_=False, by_name=False)`
+- `intersect(query1, query2, all_=False)`
+- `except_(query1, query2, all_=False)`
 
 Each builder accepts two query objects and returns a new query that compiles to
 the matching SQL set operation.
@@ -435,7 +451,7 @@ query, params = union(active_users, archived_active_users).compile()
 Use `all=True` for `UNION ALL`:
 
 ```python
-query, params = union(active_users, archived_active_users, all=True).compile()
+query, params = union(active_users, archived_active_users, all_=True).compile()
 ```
 
 Use `by_name=True` when the two result sets expose the same logical columns in
@@ -445,7 +461,7 @@ different orders:
 left = select(users.id, users.name).from_(users)
 right = select(archived_users.name, archived_users.id).from_(archived_users)
 
-query, params = union(left, right, all=True, by_name=True).compile()
+query, params = union(left, right, all_=True, by_name=True).compile()
 ```
 
 ### `intersect(...)`

{sql_fusion-1.2.1 → sql_fusion-1.2.2}/README.md

@@ -58,6 +58,22 @@ SQL Fusion is built for the middle ground:
 
 In short, the goal is to keep the ergonomics of a lightweight builder while still covering the parts of SQL that matter in real applications.
 
+### Why not SQLAlchemy ORM or Core?
+
+SQLAlchemy is an excellent tool, but it is also a much heavier and more universal system:
+
+- it brings a larger abstraction surface than this project needs
+- it is optimized for a broad ORM and Core ecosystem, not only for a small SQL builder
+- some connectors and databases still do not have first-class SQLAlchemy integrations, which can make adoption less straightforward in mixed environments
+
+SQLAlchemy Core is closer to SQL Fusion than the full ORM, but it still carries more machinery than this project is meant to expose:
+
+- it is part of a broader ecosystem with dialects, compilation layers, and extra conventions
+- it can feel more verbose when you only want a small chainable builder
+- some connectors and databases still do not have smooth SQLAlchemy Core support, so portability can depend on the backend
+
+SQL Fusion is intentionally narrower so it can stay lightweight, easy to embed, and practical for DB-API style backends without extra complexity.
+
 ## What You Get
 
 - `SELECT`, `INSERT`, `UPDATE`, and `DELETE` builders
@@ -395,9 +411,9 @@ query, params = select().from_(paid_orders).compile()
 
 SQL Fusion supports compound queries through three small wrapper classes:
 
-- `union(query1, query2, all=False, by_name=False)`
-- `intersect(q1, q2, all_=False)`
-- `except_(q1, q2, all_=False)`
+- `union(query1, query2, all_=False, by_name=False)`
+- `intersect(query1, query2, all_=False)`
+- `except_(query1, query2, all_=False)`
 
 Each builder accepts two query objects and returns a new query that compiles to
 the matching SQL set operation.
@@ -421,7 +437,7 @@ query, params = union(active_users, archived_active_users).compile()
 Use `all=True` for `UNION ALL`:
 
 ```python
-query, params = union(active_users, archived_active_users, all=True).compile()
+query, params = union(active_users, archived_active_users, all_=True).compile()
 ```
 
 Use `by_name=True` when the two result sets expose the same logical columns in
@@ -431,7 +447,7 @@ different orders:
 left = select(users.id, users.name).from_(users)
 right = select(archived_users.name, archived_users.id).from_(archived_users)
 
-query, params = union(left, right, all=True, by_name=True).compile()
+query, params = union(left, right, all_=True, by_name=True).compile()
 ```
 
 ### `intersect(...)`

{sql_fusion-1.2.1 → sql_fusion-1.2.2}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "sql_fusion"
-version = "1.2.1"
+version = "1.2.2"
 description = "Python query builder with a focus on composability and reusability."
 readme = "README.md"
 authors = [{ name = "Mastermind-U", email = "rex49513@gmail.com" }]

{sql_fusion-1.2.1 → sql_fusion-1.2.2}/src/sql_fusion/query/sets.py

@@ -57,11 +57,11 @@ class union(_set_operation):
         self,
         query1: AbstractQuery,
         query2: AbstractQuery,
-        all: bool = False,  # noqa: A002
+        all_: bool = False,
         by_name: bool = False,
     ) -> None:
         super().__init__(query1, query2)
-        self._all = all
+        self._all = all_
         self._by_name = by_name
 
     def _operator_sql(self) -> str: