surreal-orm-lite 0.35.0__tar.gz → 0.35.2__tar.gz

{surreal_orm_lite-0.35.0 → surreal_orm_lite-0.35.2}/CHANGELOG.md

@@ -5,6 +5,54 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.35.2] - 2026-10-22
+
+An auth model whose signup field is declared `Field(exclude=True)` is refused whatever its schema
+mode (#299): v0.34.1 refused it only for a `SCHEMAFULL` table, and on any other table its
+`update()` or `upsert()` dropped the stored password hash. No new public API.
+
+### Changed
+
+- **An auth model with an excluded signup field raises `TypeError` whatever its schema mode and
+  `with_table`** (#299). For a model built on `AuthenticatedUserMixin` with a field SIGNUP writes
+  that `Field(exclude=True)` keeps out of `model_dump()` (`password: str = Field(exclude=True)`),
+  `table_ddl()`, `define_table()`, `access_ddl()` and `define_access()` (with or without the
+  table) now raise `TypeError` before any request on a `SCHEMALESS` table, with no declared schema
+  mode and with `with_table=False`, as v0.34.1 did for a `SCHEMAFULL` table. `signup()` and
+  `signin()` raise the same error before any request, so an access defined by hand cannot leave
+  such a record either. The message names the model and the fields in declaration order and keeps
+  the advice: remove `exclude=True` and leave the field out where you serialise the model instead
+  (`model_dump(exclude={"password"})`). A model that relied on `exclude=True` now fails at
+  start-up instead of losing data later. Auth models without `exclude=True`, and models that are
+  not auth models, render and apply as before.
+
+### Fixed
+
+- **An auth model no longer loses its stored password hash at `update()` or `upsert()`** (#299).
+  Both replace the record with what `model_dump()` writes, so an auth model whose signup field was
+  declared `Field(exclude=True)` lost the stored value at its first `update()` or `upsert()`, with
+  no error, on a `SCHEMALESS` table (a model with neither `table_type` nor `schema_mode`) or with
+  `define_access(with_table=False)` over an optional column defined by hand
+  (`TYPE option<string>`): the hash became `NONE` and every later signin failed. With a required
+  column (`TYPE string`), the write was refused instead. Such a model is now refused before it
+  writes a record (see Changed). README section 19, "User models" and a row of "ORM behaviour:
+  SurrealDB 2.x vs 3.x" describe it; the behaviour is the same on both lines.
+
+### Notes
+
+- **Undeclared keys in list items on SurrealDB 3.x** (#301): the 0.34.1 entry below says 3.x
+  keeps a key a `SCHEMAFULL` table does not define "in the items of any list of objects,
+  `FLEXIBLE` or not". It keeps it only in the items of a list whose items define a field, such as
+  a list of sub-models `define_table()` writes, and in an object inside them that defines one. It
+  refuses it in the items of a list that defines no item field (an `array<object>` defined by hand
+  without `v.*.n`), at the top level and in a sub-model outside such a list. SurrealDB's
+  documentation of `FLEXIBLE` says every object of a `SCHEMAFULL` table, list items included,
+  accepts only the keys defined for it, so do not rely on 3.x keeping such a key. README section
+  35, the v0.7.0 and v0.34.0 rows of "ORM behaviour: SurrealDB 2.x vs 3.x" and the embedded
+  engine's "Model table DDL (v0.34.0)" row now state the exception. No ORM behaviour changes.
+- Server pins unchanged: tested against SurrealDB 3.3.4 and 2.7.0 and on the embedded engine,
+  plus 3.1.5 for backward compatibility.
+
 ## [0.35.0] - 2026-10-22
 
 Full-text search: a queryset searches text with the full SurrealDB-ORM's `search()`, and scores and

{surreal_orm_lite-0.35.0 → surreal_orm_lite-0.35.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: surreal-orm-lite
-Version: 0.35.0
+Version: 0.35.2
 Summary: Lightweight Django-style ORM for SurrealDB using the official Python SDK. Async support with Pydantic validation.
 Project-URL: Homepage, https://github.com/EulogySnowfall/SurrealDB-ORM-lite
 Project-URL: Documentation, https://github.com/EulogySnowfall/SurrealDB-ORM-lite
@@ -1333,6 +1333,13 @@ gives such a model the same table, so the two can be called in any order.
 > **The password field holds the hash.** SurrealDB returns the stored record, so
 > `result.user.password` is `$argon2id$v=19$…`, never the plaintext you submitted.
 
+**Keep the password field in `model_dump()`.** SIGNUP writes every field, while `update()` and `upsert()` replace the
+record with what `model_dump()` writes: a field declared `Field(exclude=True)` (`password: str = Field(exclude=True)`)
+would lose its stored value, the password hash, and every later signin would fail. Such a model raises `TypeError`,
+naming the fields, before any request and whatever its schema mode: `access_ddl()`, `define_access()` (with or without
+the table), `table_ddl()`, `define_table()`, `signup()` and `signin()` refuse it. Remove `exclude=True` and leave the
+field out where you serialise the model instead (`model_dump(exclude={"password"})`).
+
 #### Renewing a session (SurrealDB 3.x only)
 
 ```python
@@ -5705,13 +5712,15 @@ print(*table, sep="\n")
   declares its own.
 - A `TableType.USER` model with `extra="allow"` raises `TypeError` there (with `with_table=True`), since its table is
   `SCHEMAFULL`; a `server_fields` column without a constant default needs a database `DEFAULT` ("Field types" above).
-- A field SIGNUP writes that `Field(exclude=True)` keeps out of `model_dump()` (`password: str = Field(exclude=True)`)
-  raises `TypeError` too, naming the field, before any request (with a `SCHEMAFULL` schema mode): `define_access()`
-  with `with_table=True` and `define_table()` both refuse it, since the table would not define it, so SurrealDB 3.x
-  would refuse every signup and 2.x drop the password hash, failing every signin. Remove `exclude=True` and leave the
-  field out where you serialise the model instead (`model_dump(exclude={"password"})`): `update()` and `upsert()`
-  replace the record with what `model_dump()` writes, so even over a table defined by hand (`with_table=False`) they
-  would be refused (a required column) or drop the hash (an optional one), failing every later signin.
+- An auth model with a field SIGNUP writes that `Field(exclude=True)` keeps out of `model_dump()`
+  (`password: str = Field(exclude=True)`) raises `TypeError` too, naming the fields, before any request and whatever
+  its schema mode: `table_ddl()`, `define_table()`, `access_ddl()` and `define_access()` (with or without the table),
+  `signup()` and `signin()` refuse it. `update()` and `upsert()` replace the record with what `model_dump()` writes,
+  so on any table (`SCHEMALESS`, or defined by hand with `with_table=False`) they would drop the password hash, failing
+  every later signin, or be refused by a required column; a `SCHEMAFULL` table would not define the field either, so
+  SurrealDB 3.x would refuse every signup and 2.x drop the hash. Remove `exclude=True` and leave the field out where
+  you serialise the model instead (`model_dump(exclude={"password"})`). **Changed**: such a model on a `SCHEMALESS`
+  table or with `with_table=False` used to be accepted, and its first `update()` or `upsert()` dropped the hash.
 - Upgrading: a 0.33 `TableType.USER` model's table turns `SCHEMAFULL` at its next `define_access()`; records already
   there are checked at their next write.
 
@@ -5743,12 +5752,21 @@ print(*table, sep="\n")
   `define_table()` writes such a list `FLEXIBLE` before 3.x; the item's typed fields are still checked. 3.x keeps those
   values without it. On 2.x and the embedded engine, the items of such a list then also keep a key the model does not
   declare, written raw or by another client (the ORM never sends one), which they drop from a list that is not
-  `FLEXIBLE`: a 2.x limitation, since `FLEXIBLE` there covers the whole item. 3.x keeps such a key in the items of any
-  list of objects, `FLEXIBLE` or not, and refuses it at the top level or in a sub-model.
+  `FLEXIBLE`: a 2.x limitation, since `FLEXIBLE` there covers the whole item. 3.x keeps such a key, `FLEXIBLE` or not,
+  in the items of a list of objects whose items define a field (every list of sub-models `define_table()` writes) and
+  in an object inside them that defines one; it refuses it at the top level, in a sub-model outside such a list, and in
+  the items of a list that defines no item field (an `array<object>` defined by hand without `v.*.n`). SurrealDB's
+  [documentation of
+  `FLEXIBLE`](https://surrealdb.com/docs/reference/query-language/statements/define/field#flexible-data-types) says
+  every object of a `SCHEMAFULL` table, an item of a list included, accepts only the keys defined for it unless its
+  field is `FLEXIBLE`: 3.x departs from it in a list whose items define a field, so a later 3.x may refuse such a key
+  there too: do not rely on it.
 - On SurrealDB 3.x a required untyped array refuses an object item unless its items are defined
   (`no such field exists`): `define_table()` writes the item definition `TYPE any` (`bag.*`) on every line.
 - A write naming a field a `SCHEMAFULL` table does not define is refused on 3.x and dropped on 2.x and the embedded
-  engine ("What SurrealDB checks" above).
+  engine ("What SurrealDB checks" above), except in the items of a list of objects: on 3.x of a list whose items define
+  a field (every list of sub-models `define_table()` writes), on 2.x and the embedded engine of a list `define_table()`
+  writes `FLEXIBLE`.
 - `COMPUTED` fields are SurrealDB 3.x's: `define_table()` keeps a stored one `COMPUTED`, and writes a new computed
   field `VALUE` on both lines.
 - The [2.x/3.x table](#orm-behaviour-surrealdb-2x-vs-3x) and the
@@ -6249,7 +6267,7 @@ features introduced in SurrealDB 3.x. On 2.x the ORM degrades gracefully. Capabi
 listed behave the same on both lines. The 2.x column was measured on 2.6.5 and holds unchanged
 on 2.7.0. The 3.x column was measured on 3.2.4 and holds on 3.3.0, except where a row says
 otherwise. The full suite and every divergence below were re-verified on both new versions.
-Rows added in v0.20.0 were measured directly on 2.7.0 and 3.3.0; rows added in v0.21.0 on 2.7.0 and 3.3.2, re-verified on 3.3.3, with 3.1.5 where it differs; rows added in v0.22.0 on 2.7.0 and 3.3.3, with 3.1.5 where it differs; rows added in v0.23.0 on 2.7.0 and 3.3.4, with 3.1.5 where it differs; rows added in v0.24.0 on 2.7.0 and 3.3.4, identical on 3.1.5; rows added in v0.26.0 on 2.7.0 and 3.3.4, in memory and on versioned storage, identical on 3.1.5; rows added in v0.27.0 on 2.7.0 and 3.3.4, with 3.1.5 where it differs; rows added in v0.28.0 on 2.7.0 and 3.3.4, identical on 3.1.5; the rows added in v0.28.1 on 2.7.0 and 3.3.4, identical on 3.1.5; rows added in v0.29.0 on 2.7.0 and 3.3.4 in one process, identical on 3.1.5. The row added in v0.29.2 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. Rows added in v0.30.0 were measured on 2.7.0, 3.3.4 and the embedded engine, with 3.1.5 where it differs. The row added in v0.30.3 was measured on 2.7.0 and 3.3.4, over WebSocket and HTTP, and on the embedded engine, identical on 3.1.5. The row added in v0.30.7 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5: its parser refuses a statement that nests six objects, and `update()` nests at most four. Rows added in v0.31.0 were measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. The row added in v0.31.1 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. Rows added in v0.32.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4 but accepts raw writes to a view. Rows added in v0.33.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4. Rows added in v0.34.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4 except that it refuses a Python `set` written to a `set` field, and an object item of an optional untyped `list`. Rows added in v0.35.0 were measured on 2.7.0, 3.3.4 and the embedded engine, with 3.1.5 where it differs.
+Rows added in v0.20.0 were measured directly on 2.7.0 and 3.3.0; rows added in v0.21.0 on 2.7.0 and 3.3.2, re-verified on 3.3.3, with 3.1.5 where it differs; rows added in v0.22.0 on 2.7.0 and 3.3.3, with 3.1.5 where it differs; rows added in v0.23.0 on 2.7.0 and 3.3.4, with 3.1.5 where it differs; rows added in v0.24.0 on 2.7.0 and 3.3.4, identical on 3.1.5; rows added in v0.26.0 on 2.7.0 and 3.3.4, in memory and on versioned storage, identical on 3.1.5; rows added in v0.27.0 on 2.7.0 and 3.3.4, with 3.1.5 where it differs; rows added in v0.28.0 on 2.7.0 and 3.3.4, identical on 3.1.5; the rows added in v0.28.1 on 2.7.0 and 3.3.4, identical on 3.1.5; rows added in v0.29.0 on 2.7.0 and 3.3.4 in one process, identical on 3.1.5. The row added in v0.29.2 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. Rows added in v0.30.0 were measured on 2.7.0, 3.3.4 and the embedded engine, with 3.1.5 where it differs. The row added in v0.30.3 was measured on 2.7.0 and 3.3.4, over WebSocket and HTTP, and on the embedded engine, identical on 3.1.5. The row added in v0.30.7 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5: its parser refuses a statement that nests six objects, and `update()` nests at most four. Rows added in v0.31.0 were measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. The row added in v0.31.1 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. Rows added in v0.32.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4 but accepts raw writes to a view. Rows added in v0.33.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4. Rows added in v0.34.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4 except that it refuses a Python `set` written to a `set` field, and an object item of an optional untyped `list`. Rows added in v0.35.0 were measured on 2.7.0, 3.3.4 and the embedded engine, with 3.1.5 where it differs. The row added in v0.35.2 was measured on 2.7.0 and 3.3.4, identical on 3.1.5.
 The SDK's in-process engine has a table of its own: [ORM behaviour: the embedded engine](#orm-behaviour-the-embedded-engine).
 
 | ORM capability                                                                                                                         | SurrealDB 2.6.x / 2.7.x                                                                                                                                                       | SurrealDB 3.2.x / 3.3.x                                                                                                                                                             | Since                                |
@@ -6263,7 +6281,7 @@ The SDK's in-process engine has a table of its own: [ORM behaviour: the embedded
 | Cleanup on a missing target (`delete_table`)                                                                                           | native no-op                                                                                                                                                                  | ORM makes it a silent no-op                                                                                                                                                         | v0.7.0                               |
 | Aggregation over an empty set (`NaN` / `±inf`)                                                                                         | returns `0.0` / `None`                                                                                                                                                        | ORM normalises to `0.0` / `None`                                                                                                                                                    | v0.7.0                               |
 | Namespace/db selection (`use()` ordering)                                                                                              | lenient (auto-creates)                                                                                                                                                        | strict — ORM signs in before `use()`                                                                                                                                                | v0.7.0                               |
-| Writing a field a `SCHEMAFULL` table does not define (`CREATE`, `INSERT`, `INSERT RELATION`)                                           | silently dropped: the record is stored without it                                                                                                                             | rejected ("Found field …, but no such field exists"): nothing is stored                                                                                                             | v0.7.0                               |
+| Writing a field a `SCHEMAFULL` table does not define (`CREATE`, `INSERT`, `INSERT RELATION`)                                           | silently dropped: the record is stored without it; kept in the items of a list `define_table()` writes `FLEXIBLE` (a 2.x limitation)                                          | rejected ("Found field …, but no such field exists"): nothing is stored, except in the items of a list whose items define a field (every list of sub-models), which keep it         | v0.7.0                               |
 | `upsert()` / `update_or_create()` / `get_or_create()`                                                                                  | same on both lines                                                                                                                                                            | same on both lines                                                                                                                                                                  | v0.10.0                              |
 | `patch()` / `atomic_append` / `atomic_set_add` / `atomic_remove` / `atomic_increment`                                                  | same on both lines (portable `array::*` fns chosen over divergent `+=`/`-=`)                                                                                                  | same on both lines                                                                                                                                                                  | v0.11.0                              |
 | `retry_on_conflict` / `SurrealDbConflictError` (retryable conflict)                                                                    | same type + decorator; conflicts rarer (engine serialises more), except on `CHANGEFEED` tables (section 22)                                                                   | same type + decorator; conflicts are the normal optimistic-MVCC failure                                                                                                             | v0.12.0                              |
@@ -6391,7 +6409,7 @@ The SDK's in-process engine has a table of its own: [ORM behaviour: the embedded
 | Model table DDL (`define_table()`: `DEFINE TABLE` + `DEFINE FIELD`)                                                                    | same on both lines: one `DEFINE TABLE OVERWRITE` and one `DEFINE FIELD OVERWRITE` per column, keeping what the model does not declare                                         | the same                                                                                                                                                                            | v0.34.0                              |
 | An `Any` or untyped `list`/`set` field of a `SCHEMAFULL` model                                                                         | `define_table()` adds `FLEXIBLE` (read from `client.version()`): without it these engines empty such values, optional or not; the item definitions as on 3.x                  | kept without `FLEXIBLE` (refused there); an untyped `list` gets an item definition `TYPE any`, without which 3.x refuses an object item of a required one (`no such field exists`)  | v0.34.0                              |
 | A `list` of sub-models (`list[M]`, at any depth) holding a `dict`, an `Any` or an untyped `list`, in a `SCHEMAFULL` model              | `define_table()` also writes the `list` `FLEXIBLE`: without it these engines drop such a value from every item, then refuse the record's next write (`Found NONE for field`)  | kept without `FLEXIBLE` on the `list`, which `define_table()` does not write there                                                                                                  | v0.34.0                              |
-| A write naming a field a `SCHEMAFULL` table does not define (an undeclared `merge()` key, a raw query, records predating `SCHEMAFULL`) | the field is dropped, silently; kept in the items of a list `define_table()` writes `FLEXIBLE` (a 2.x limitation)                                                             | the write is refused (`no such field exists`), except in the items of a list of objects, which keep it                                                                              | v0.34.0                              |
+| A write naming a field a `SCHEMAFULL` table does not define (an undeclared `merge()` key, a raw query, records predating `SCHEMAFULL`) | the field is dropped, silently; kept in the items of a list `define_table()` writes `FLEXIBLE` (a 2.x limitation)                                                             | the write is refused (`no such field exists`), except in the items of a list whose items define a field (every list of sub-models `define_table()` writes), which keep it           | v0.34.0                              |
 | Full-text index (`define_indexes()`, `index_ddl(line=)`)                                                                               | `SEARCH ANALYZER` (`FULLTEXT` is a parse error), read from `client.version()`; several fields accepted, the ORM writes one                                                    | `FULLTEXT ANALYZER` (`SEARCH` is a parse error); one field per index                                                                                                                | v0.35.0                              |
 | Removing an analyzer an index uses (`remove_analyzer()`)                                                                               | the server would accept it, then refuse every write to the table: the ORM refuses it first, with 3.x's message                                                                | refused by the server                                                                                                                                                               | v0.35.0                              |
 | BM25 score of a term in more than half the documents (`SearchScore`)                                                                   | below zero: a text holding such a term scores lower than without it, and ranks differently than on 3.x                                                                        | `0.0`: the term adds nothing to the score                                                                                                                                           | v0.35.0                              |
@@ -6399,6 +6417,7 @@ The SDK's in-process engine has a table of its own: [ORM behaviour: the embedded
 | Two `search()` fields AND-ed                                                                                                           | only the records matching every field, each field scored as if searched alone                                                                                                 | the same on 3.3; 3.1 can also return records that match only one of the fields, scored `0.0` on the other                                                                           | v0.35.0                              |
 | `search()` on a field without a full-text index                                                                                        | `SurrealDbError` naming the field                                                                                                                                             | the same; 3.1 answers no record                                                                                                                                                     | v0.35.0                              |
 | `live()` with a `Subquery` that searches a field without a full-text index                                                             | `SurrealDbError` naming the field, before the live query starts                                                                                                               | the same (the live query would never notify); 3.1 starts it                                                                                                                         | v0.35.0                              |
+| An auth model with a `Field(exclude=True)` field SIGNUP writes (`password: str = Field(exclude=True)`)                                 | `TypeError` before any request, whatever the schema mode and `with_table`: the four DDL methods, `signup()` and `signin()`                                                    | same on both lines (a check of the model, no request)                                                                                                                               | v0.35.2                              |
 | Full suite and every divergence in this table, re-run on SurrealDB 2.7.0 and 3.3.0                                                     | 2.7.0 identical to 2.6.5 (same passes, same 3.x-only skips)                                                                                                                   | 3.3.0 identical to 3.2.4, except the system-user signin row                                                                                                                         | v0.19.1                              |
 
 > **Note on record IDs**: A record loaded from the database has its `id` field set to a native `surrealdb.RecordID` object, not a plain string. Use `model.get_raw_id()` to obtain the bare identifier string (e.g. `"alice"`), or compare directly with `model.id == RecordID("User", "alice")`. In-memory instances you construct yourself retain whatever value you assign.
@@ -6434,7 +6453,7 @@ Capabilities not listed behave as on a 2.x server.
 | Server-side events and stored functions (v0.31.0)                   | as on a 2.x server: `$input` is `NONE`; `Event(async_mode=True)` raises `SurrealDbError` before any DDL                                                                                                                                                                                                                                               | `ASYNC` events on 3.x                                                                                           | v0.31.0 |
 | Materialized views (v0.32.0)                                        | as on a 2.x server: `int` sums and `Decimal` means; in a grouped view, `math::stddev()`/`math::variance()`, an expression around an aggregate, a field outside `GROUP BY` and a `GROUP BY` on an alias raise `SurrealDbError` before any DDL; writes to a view refused by the ORM (the engine would accept them); no live queries                     | `float` sums and means on 3.x                                                                                   | v0.32.0 |
 | TYPE RELATION constraints (v0.33.0)                                 | as on a 2.x server: a raw `ALTER TABLE … TYPE` of a table already written to is not enforced (`define_relation()` sends `DEFINE TABLE OVERWRITE`); an endpoint outside `IN`/`OUT` whose record does not exist raises `SurrealDbNotFoundError`                                                                                                         | `SurrealDbError` for that endpoint on 3.x                                                                       | v0.33.0 |
-| Model table DDL (v0.34.0)                                           | as on a 2.x server: `define_table()` adds `FLEXIBLE` to the `Any` and untyped columns of a `SCHEMAFULL` table and to its lists of sub-models holding a `FLEXIBLE` column; a write naming a field the table does not define drops that field                                                                                                           | 3.x keeps those values without `FLEXIBLE` and refuses that write                                                | v0.34.0 |
+| Model table DDL (v0.34.0)                                           | as on a 2.x server: `define_table()` adds `FLEXIBLE` to the `Any` and untyped columns of a `SCHEMAFULL` table and to its lists of sub-models holding a `FLEXIBLE` column; a write naming a field the table does not define drops that field, except in the items of a list `define_table()` writes `FLEXIBLE`, which keep it                          | 3.x keeps those values without `FLEXIBLE` and refuses that write, except in list items that define a field      | v0.34.0 |
 | Full-text search (v0.35.0)                                          | as on a 2.x server: `SEARCH ANALYZER`, a term in more than half the documents scores below zero, BM25 statistics grow with each rebuild and keep deleted records, `remove_analyzer()` refuses an analyzer an index uses; an index defined in the transaction that defines its analyzer sees it, which `define_indexes(tx=…)` refuses all the same     | 3.x writes `FULLTEXT ANALYZER`, scores such a term `0.0`, keeps BM25 statistics exact and refuses that removal  | v0.35.0 |
 | Everything else                                                     | CRUD, QuerySet, aggregations, relations, typed edges, rich and geo fields, upsert/patch, server values, computed fields, stored functions, signals: the same as on a 2.x server                                                                                                                                                                       | unchanged                                                                                                       | v0.25.0 |
 

{surreal_orm_lite-0.35.0 → surreal_orm_lite-0.35.2}/README.md

@@ -1282,6 +1282,13 @@ gives such a model the same table, so the two can be called in any order.
 > **The password field holds the hash.** SurrealDB returns the stored record, so
 > `result.user.password` is `$argon2id$v=19$…`, never the plaintext you submitted.
 
+**Keep the password field in `model_dump()`.** SIGNUP writes every field, while `update()` and `upsert()` replace the
+record with what `model_dump()` writes: a field declared `Field(exclude=True)` (`password: str = Field(exclude=True)`)
+would lose its stored value, the password hash, and every later signin would fail. Such a model raises `TypeError`,
+naming the fields, before any request and whatever its schema mode: `access_ddl()`, `define_access()` (with or without
+the table), `table_ddl()`, `define_table()`, `signup()` and `signin()` refuse it. Remove `exclude=True` and leave the
+field out where you serialise the model instead (`model_dump(exclude={"password"})`).
+
 #### Renewing a session (SurrealDB 3.x only)
 
 ```python
@@ -5654,13 +5661,15 @@ print(*table, sep="\n")
   declares its own.
 - A `TableType.USER` model with `extra="allow"` raises `TypeError` there (with `with_table=True`), since its table is
   `SCHEMAFULL`; a `server_fields` column without a constant default needs a database `DEFAULT` ("Field types" above).
-- A field SIGNUP writes that `Field(exclude=True)` keeps out of `model_dump()` (`password: str = Field(exclude=True)`)
-  raises `TypeError` too, naming the field, before any request (with a `SCHEMAFULL` schema mode): `define_access()`
-  with `with_table=True` and `define_table()` both refuse it, since the table would not define it, so SurrealDB 3.x
-  would refuse every signup and 2.x drop the password hash, failing every signin. Remove `exclude=True` and leave the
-  field out where you serialise the model instead (`model_dump(exclude={"password"})`): `update()` and `upsert()`
-  replace the record with what `model_dump()` writes, so even over a table defined by hand (`with_table=False`) they
-  would be refused (a required column) or drop the hash (an optional one), failing every later signin.
+- An auth model with a field SIGNUP writes that `Field(exclude=True)` keeps out of `model_dump()`
+  (`password: str = Field(exclude=True)`) raises `TypeError` too, naming the fields, before any request and whatever
+  its schema mode: `table_ddl()`, `define_table()`, `access_ddl()` and `define_access()` (with or without the table),
+  `signup()` and `signin()` refuse it. `update()` and `upsert()` replace the record with what `model_dump()` writes,
+  so on any table (`SCHEMALESS`, or defined by hand with `with_table=False`) they would drop the password hash, failing
+  every later signin, or be refused by a required column; a `SCHEMAFULL` table would not define the field either, so
+  SurrealDB 3.x would refuse every signup and 2.x drop the hash. Remove `exclude=True` and leave the field out where
+  you serialise the model instead (`model_dump(exclude={"password"})`). **Changed**: such a model on a `SCHEMALESS`
+  table or with `with_table=False` used to be accepted, and its first `update()` or `upsert()` dropped the hash.
 - Upgrading: a 0.33 `TableType.USER` model's table turns `SCHEMAFULL` at its next `define_access()`; records already
   there are checked at their next write.
 
@@ -5692,12 +5701,21 @@ print(*table, sep="\n")
   `define_table()` writes such a list `FLEXIBLE` before 3.x; the item's typed fields are still checked. 3.x keeps those
   values without it. On 2.x and the embedded engine, the items of such a list then also keep a key the model does not
   declare, written raw or by another client (the ORM never sends one), which they drop from a list that is not
-  `FLEXIBLE`: a 2.x limitation, since `FLEXIBLE` there covers the whole item. 3.x keeps such a key in the items of any
-  list of objects, `FLEXIBLE` or not, and refuses it at the top level or in a sub-model.
+  `FLEXIBLE`: a 2.x limitation, since `FLEXIBLE` there covers the whole item. 3.x keeps such a key, `FLEXIBLE` or not,
+  in the items of a list of objects whose items define a field (every list of sub-models `define_table()` writes) and
+  in an object inside them that defines one; it refuses it at the top level, in a sub-model outside such a list, and in
+  the items of a list that defines no item field (an `array<object>` defined by hand without `v.*.n`). SurrealDB's
+  [documentation of
+  `FLEXIBLE`](https://surrealdb.com/docs/reference/query-language/statements/define/field#flexible-data-types) says
+  every object of a `SCHEMAFULL` table, an item of a list included, accepts only the keys defined for it unless its
+  field is `FLEXIBLE`: 3.x departs from it in a list whose items define a field, so a later 3.x may refuse such a key
+  there too: do not rely on it.
 - On SurrealDB 3.x a required untyped array refuses an object item unless its items are defined
   (`no such field exists`): `define_table()` writes the item definition `TYPE any` (`bag.*`) on every line.
 - A write naming a field a `SCHEMAFULL` table does not define is refused on 3.x and dropped on 2.x and the embedded
-  engine ("What SurrealDB checks" above).
+  engine ("What SurrealDB checks" above), except in the items of a list of objects: on 3.x of a list whose items define
+  a field (every list of sub-models `define_table()` writes), on 2.x and the embedded engine of a list `define_table()`
+  writes `FLEXIBLE`.
 - `COMPUTED` fields are SurrealDB 3.x's: `define_table()` keeps a stored one `COMPUTED`, and writes a new computed
   field `VALUE` on both lines.
 - The [2.x/3.x table](#orm-behaviour-surrealdb-2x-vs-3x) and the
@@ -6198,7 +6216,7 @@ features introduced in SurrealDB 3.x. On 2.x the ORM degrades gracefully. Capabi
 listed behave the same on both lines. The 2.x column was measured on 2.6.5 and holds unchanged
 on 2.7.0. The 3.x column was measured on 3.2.4 and holds on 3.3.0, except where a row says
 otherwise. The full suite and every divergence below were re-verified on both new versions.
-Rows added in v0.20.0 were measured directly on 2.7.0 and 3.3.0; rows added in v0.21.0 on 2.7.0 and 3.3.2, re-verified on 3.3.3, with 3.1.5 where it differs; rows added in v0.22.0 on 2.7.0 and 3.3.3, with 3.1.5 where it differs; rows added in v0.23.0 on 2.7.0 and 3.3.4, with 3.1.5 where it differs; rows added in v0.24.0 on 2.7.0 and 3.3.4, identical on 3.1.5; rows added in v0.26.0 on 2.7.0 and 3.3.4, in memory and on versioned storage, identical on 3.1.5; rows added in v0.27.0 on 2.7.0 and 3.3.4, with 3.1.5 where it differs; rows added in v0.28.0 on 2.7.0 and 3.3.4, identical on 3.1.5; the rows added in v0.28.1 on 2.7.0 and 3.3.4, identical on 3.1.5; rows added in v0.29.0 on 2.7.0 and 3.3.4 in one process, identical on 3.1.5. The row added in v0.29.2 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. Rows added in v0.30.0 were measured on 2.7.0, 3.3.4 and the embedded engine, with 3.1.5 where it differs. The row added in v0.30.3 was measured on 2.7.0 and 3.3.4, over WebSocket and HTTP, and on the embedded engine, identical on 3.1.5. The row added in v0.30.7 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5: its parser refuses a statement that nests six objects, and `update()` nests at most four. Rows added in v0.31.0 were measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. The row added in v0.31.1 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. Rows added in v0.32.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4 but accepts raw writes to a view. Rows added in v0.33.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4. Rows added in v0.34.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4 except that it refuses a Python `set` written to a `set` field, and an object item of an optional untyped `list`. Rows added in v0.35.0 were measured on 2.7.0, 3.3.4 and the embedded engine, with 3.1.5 where it differs.
+Rows added in v0.20.0 were measured directly on 2.7.0 and 3.3.0; rows added in v0.21.0 on 2.7.0 and 3.3.2, re-verified on 3.3.3, with 3.1.5 where it differs; rows added in v0.22.0 on 2.7.0 and 3.3.3, with 3.1.5 where it differs; rows added in v0.23.0 on 2.7.0 and 3.3.4, with 3.1.5 where it differs; rows added in v0.24.0 on 2.7.0 and 3.3.4, identical on 3.1.5; rows added in v0.26.0 on 2.7.0 and 3.3.4, in memory and on versioned storage, identical on 3.1.5; rows added in v0.27.0 on 2.7.0 and 3.3.4, with 3.1.5 where it differs; rows added in v0.28.0 on 2.7.0 and 3.3.4, identical on 3.1.5; the rows added in v0.28.1 on 2.7.0 and 3.3.4, identical on 3.1.5; rows added in v0.29.0 on 2.7.0 and 3.3.4 in one process, identical on 3.1.5. The row added in v0.29.2 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. Rows added in v0.30.0 were measured on 2.7.0, 3.3.4 and the embedded engine, with 3.1.5 where it differs. The row added in v0.30.3 was measured on 2.7.0 and 3.3.4, over WebSocket and HTTP, and on the embedded engine, identical on 3.1.5. The row added in v0.30.7 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5: its parser refuses a statement that nests six objects, and `update()` nests at most four. Rows added in v0.31.0 were measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. The row added in v0.31.1 was measured on 2.7.0, 3.3.4 and the embedded engine, identical on 3.1.5. Rows added in v0.32.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4 but accepts raw writes to a view. Rows added in v0.33.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4. Rows added in v0.34.0 were measured on 2.7.0, 3.3.4 and the embedded engine; 3.1.5 behaves as 3.3.4 except that it refuses a Python `set` written to a `set` field, and an object item of an optional untyped `list`. Rows added in v0.35.0 were measured on 2.7.0, 3.3.4 and the embedded engine, with 3.1.5 where it differs. The row added in v0.35.2 was measured on 2.7.0 and 3.3.4, identical on 3.1.5.
 The SDK's in-process engine has a table of its own: [ORM behaviour: the embedded engine](#orm-behaviour-the-embedded-engine).
 
 | ORM capability                                                                                                                         | SurrealDB 2.6.x / 2.7.x                                                                                                                                                       | SurrealDB 3.2.x / 3.3.x                                                                                                                                                             | Since                                |
@@ -6212,7 +6230,7 @@ The SDK's in-process engine has a table of its own: [ORM behaviour: the embedded
 | Cleanup on a missing target (`delete_table`)                                                                                           | native no-op                                                                                                                                                                  | ORM makes it a silent no-op                                                                                                                                                         | v0.7.0                               |
 | Aggregation over an empty set (`NaN` / `±inf`)                                                                                         | returns `0.0` / `None`                                                                                                                                                        | ORM normalises to `0.0` / `None`                                                                                                                                                    | v0.7.0                               |
 | Namespace/db selection (`use()` ordering)                                                                                              | lenient (auto-creates)                                                                                                                                                        | strict — ORM signs in before `use()`                                                                                                                                                | v0.7.0                               |
-| Writing a field a `SCHEMAFULL` table does not define (`CREATE`, `INSERT`, `INSERT RELATION`)                                           | silently dropped: the record is stored without it                                                                                                                             | rejected ("Found field …, but no such field exists"): nothing is stored                                                                                                             | v0.7.0                               |
+| Writing a field a `SCHEMAFULL` table does not define (`CREATE`, `INSERT`, `INSERT RELATION`)                                           | silently dropped: the record is stored without it; kept in the items of a list `define_table()` writes `FLEXIBLE` (a 2.x limitation)                                          | rejected ("Found field …, but no such field exists"): nothing is stored, except in the items of a list whose items define a field (every list of sub-models), which keep it         | v0.7.0                               |
 | `upsert()` / `update_or_create()` / `get_or_create()`                                                                                  | same on both lines                                                                                                                                                            | same on both lines                                                                                                                                                                  | v0.10.0                              |
 | `patch()` / `atomic_append` / `atomic_set_add` / `atomic_remove` / `atomic_increment`                                                  | same on both lines (portable `array::*` fns chosen over divergent `+=`/`-=`)                                                                                                  | same on both lines                                                                                                                                                                  | v0.11.0                              |
 | `retry_on_conflict` / `SurrealDbConflictError` (retryable conflict)                                                                    | same type + decorator; conflicts rarer (engine serialises more), except on `CHANGEFEED` tables (section 22)                                                                   | same type + decorator; conflicts are the normal optimistic-MVCC failure                                                                                                             | v0.12.0                              |
@@ -6340,7 +6358,7 @@ The SDK's in-process engine has a table of its own: [ORM behaviour: the embedded
 | Model table DDL (`define_table()`: `DEFINE TABLE` + `DEFINE FIELD`)                                                                    | same on both lines: one `DEFINE TABLE OVERWRITE` and one `DEFINE FIELD OVERWRITE` per column, keeping what the model does not declare                                         | the same                                                                                                                                                                            | v0.34.0                              |
 | An `Any` or untyped `list`/`set` field of a `SCHEMAFULL` model                                                                         | `define_table()` adds `FLEXIBLE` (read from `client.version()`): without it these engines empty such values, optional or not; the item definitions as on 3.x                  | kept without `FLEXIBLE` (refused there); an untyped `list` gets an item definition `TYPE any`, without which 3.x refuses an object item of a required one (`no such field exists`)  | v0.34.0                              |
 | A `list` of sub-models (`list[M]`, at any depth) holding a `dict`, an `Any` or an untyped `list`, in a `SCHEMAFULL` model              | `define_table()` also writes the `list` `FLEXIBLE`: without it these engines drop such a value from every item, then refuse the record's next write (`Found NONE for field`)  | kept without `FLEXIBLE` on the `list`, which `define_table()` does not write there                                                                                                  | v0.34.0                              |
-| A write naming a field a `SCHEMAFULL` table does not define (an undeclared `merge()` key, a raw query, records predating `SCHEMAFULL`) | the field is dropped, silently; kept in the items of a list `define_table()` writes `FLEXIBLE` (a 2.x limitation)                                                             | the write is refused (`no such field exists`), except in the items of a list of objects, which keep it                                                                              | v0.34.0                              |
+| A write naming a field a `SCHEMAFULL` table does not define (an undeclared `merge()` key, a raw query, records predating `SCHEMAFULL`) | the field is dropped, silently; kept in the items of a list `define_table()` writes `FLEXIBLE` (a 2.x limitation)                                                             | the write is refused (`no such field exists`), except in the items of a list whose items define a field (every list of sub-models `define_table()` writes), which keep it           | v0.34.0                              |
 | Full-text index (`define_indexes()`, `index_ddl(line=)`)                                                                               | `SEARCH ANALYZER` (`FULLTEXT` is a parse error), read from `client.version()`; several fields accepted, the ORM writes one                                                    | `FULLTEXT ANALYZER` (`SEARCH` is a parse error); one field per index                                                                                                                | v0.35.0                              |
 | Removing an analyzer an index uses (`remove_analyzer()`)                                                                               | the server would accept it, then refuse every write to the table: the ORM refuses it first, with 3.x's message                                                                | refused by the server                                                                                                                                                               | v0.35.0                              |
 | BM25 score of a term in more than half the documents (`SearchScore`)                                                                   | below zero: a text holding such a term scores lower than without it, and ranks differently than on 3.x                                                                        | `0.0`: the term adds nothing to the score                                                                                                                                           | v0.35.0                              |
@@ -6348,6 +6366,7 @@ The SDK's in-process engine has a table of its own: [ORM behaviour: the embedded
 | Two `search()` fields AND-ed                                                                                                           | only the records matching every field, each field scored as if searched alone                                                                                                 | the same on 3.3; 3.1 can also return records that match only one of the fields, scored `0.0` on the other                                                                           | v0.35.0                              |
 | `search()` on a field without a full-text index                                                                                        | `SurrealDbError` naming the field                                                                                                                                             | the same; 3.1 answers no record                                                                                                                                                     | v0.35.0                              |
 | `live()` with a `Subquery` that searches a field without a full-text index                                                             | `SurrealDbError` naming the field, before the live query starts                                                                                                               | the same (the live query would never notify); 3.1 starts it                                                                                                                         | v0.35.0                              |
+| An auth model with a `Field(exclude=True)` field SIGNUP writes (`password: str = Field(exclude=True)`)                                 | `TypeError` before any request, whatever the schema mode and `with_table`: the four DDL methods, `signup()` and `signin()`                                                    | same on both lines (a check of the model, no request)                                                                                                                               | v0.35.2                              |
 | Full suite and every divergence in this table, re-run on SurrealDB 2.7.0 and 3.3.0                                                     | 2.7.0 identical to 2.6.5 (same passes, same 3.x-only skips)                                                                                                                   | 3.3.0 identical to 3.2.4, except the system-user signin row                                                                                                                         | v0.19.1                              |
 
 > **Note on record IDs**: A record loaded from the database has its `id` field set to a native `surrealdb.RecordID` object, not a plain string. Use `model.get_raw_id()` to obtain the bare identifier string (e.g. `"alice"`), or compare directly with `model.id == RecordID("User", "alice")`. In-memory instances you construct yourself retain whatever value you assign.
@@ -6383,7 +6402,7 @@ Capabilities not listed behave as on a 2.x server.
 | Server-side events and stored functions (v0.31.0)                   | as on a 2.x server: `$input` is `NONE`; `Event(async_mode=True)` raises `SurrealDbError` before any DDL                                                                                                                                                                                                                                               | `ASYNC` events on 3.x                                                                                           | v0.31.0 |
 | Materialized views (v0.32.0)                                        | as on a 2.x server: `int` sums and `Decimal` means; in a grouped view, `math::stddev()`/`math::variance()`, an expression around an aggregate, a field outside `GROUP BY` and a `GROUP BY` on an alias raise `SurrealDbError` before any DDL; writes to a view refused by the ORM (the engine would accept them); no live queries                     | `float` sums and means on 3.x                                                                                   | v0.32.0 |
 | TYPE RELATION constraints (v0.33.0)                                 | as on a 2.x server: a raw `ALTER TABLE … TYPE` of a table already written to is not enforced (`define_relation()` sends `DEFINE TABLE OVERWRITE`); an endpoint outside `IN`/`OUT` whose record does not exist raises `SurrealDbNotFoundError`                                                                                                         | `SurrealDbError` for that endpoint on 3.x                                                                       | v0.33.0 |
-| Model table DDL (v0.34.0)                                           | as on a 2.x server: `define_table()` adds `FLEXIBLE` to the `Any` and untyped columns of a `SCHEMAFULL` table and to its lists of sub-models holding a `FLEXIBLE` column; a write naming a field the table does not define drops that field                                                                                                           | 3.x keeps those values without `FLEXIBLE` and refuses that write                                                | v0.34.0 |
+| Model table DDL (v0.34.0)                                           | as on a 2.x server: `define_table()` adds `FLEXIBLE` to the `Any` and untyped columns of a `SCHEMAFULL` table and to its lists of sub-models holding a `FLEXIBLE` column; a write naming a field the table does not define drops that field, except in the items of a list `define_table()` writes `FLEXIBLE`, which keep it                          | 3.x keeps those values without `FLEXIBLE` and refuses that write, except in list items that define a field      | v0.34.0 |
 | Full-text search (v0.35.0)                                          | as on a 2.x server: `SEARCH ANALYZER`, a term in more than half the documents scores below zero, BM25 statistics grow with each rebuild and keep deleted records, `remove_analyzer()` refuses an analyzer an index uses; an index defined in the transaction that defines its analyzer sees it, which `define_indexes(tx=…)` refuses all the same     | 3.x writes `FULLTEXT ANALYZER`, scores such a term `0.0`, keeps BM25 statistics exact and refuses that removal  | v0.35.0 |
 | Everything else                                                     | CRUD, QuerySet, aggregations, relations, typed edges, rich and geo fields, upsert/patch, server values, computed fields, stored functions, signals: the same as on a 2.x server                                                                                                                                                                       | unchanged                                                                                                       | v0.25.0 |
 

{surreal_orm_lite-0.35.0 → surreal_orm_lite-0.35.2}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "surreal-orm-lite"
-version = "0.35.0"
+version = "0.35.2"
 description = "Lightweight Django-style ORM for SurrealDB using the official Python SDK. Async support with Pydantic validation."
 readme = "README.md"
 requires-python = ">=3.11"

{surreal_orm_lite-0.35.0 → surreal_orm_lite-0.35.2}/src/surreal_orm_lite/__init__.py

@@ -1,4 +1,4 @@
-__version__ = "0.35.0"
+__version__ = "0.35.2"
 
 from ._sdk import BoundExcluded, BoundIncluded
 from .aggregations import Aggregation, Avg, Count, Max, Min, Sum

{surreal_orm_lite-0.35.0 → surreal_orm_lite-0.35.2}/src/surreal_orm_lite/model_auth.py

@@ -38,7 +38,7 @@ from .auth import AuthTokens, build_auth_payload, wrap_auth_error
 from .connection_manager import SurrealDBConnectionManager
 from .embedded import model_auth_unsupported
 from .exceptions import SurrealDbAuthenticationError, SurrealDbError
-from .schema import TableClauses, declared_clauses
+from .schema import TableClauses, declared_clauses, signup_excluded_refused
 from .transaction import Transaction
 from .types import SchemaMode
 from .utils import apply_ddl_statements, validate_alias_name, validate_field_name
@@ -268,17 +268,33 @@ class AuthenticatedUserMixin:
     @classmethod
     def _signup_fields_excluded(cls) -> list[str]:
         """The fields SIGNUP writes that ``Field(exclude=True)`` keeps out of ``model_dump()``, in declaration order
-        (#296).
-
-        The model table DDL defines the columns ``model_dump()`` writes (``model_ddl.model_columns()`` skips the same
-        fields), while SIGNUP writes every field of :meth:`_signup_fields` — so on a ``SCHEMAFULL`` table these have no
-        column: SurrealDB 3.x refuses the signup, 2.x drops their values (a password hash, and every signin fails).
-        ``BaseSurrealModel._table_ddl()`` refuses such a table (SG1), behind ``table_ddl()``, ``define_table()``,
-        :meth:`access_ddl` and :meth:`define_access`.
+        (#296, #299).
+
+        SIGNUP writes every field of :meth:`_signup_fields`, while ``update()`` and ``upsert()`` replace the stored
+        record with what ``model_dump()`` writes, whatever the table's schema mode — so they drop these values (a
+        password hash, and every later signin fails), or a required column refuses them —, and the model table DDL
+        defines the columns ``model_dump()`` writes (``model_ddl.model_columns()`` skips the same fields), so on a
+        ``SCHEMAFULL`` table these have no column: SurrealDB 3.x refuses the signup, 2.x drops their values.
+        :meth:`_refuse_signup_fields_excluded` refuses such a model (SG1).
         """
         fields = getattr(cls, "model_fields", {}) or {}
         return [name for name in cls._signup_fields() if fields[name].exclude is True]
 
+    @classmethod
+    def _refuse_signup_fields_excluded(cls) -> None:
+        """SG1 (#296, #299): refuse a model with a field SIGNUP writes that ``Field(exclude=True)`` keeps out of
+        ``model_dump()`` (:meth:`_signup_fields_excluded`), whatever its schema mode. Pure:
+        ``BaseSurrealModel._table_ddl()`` (behind ``table_ddl()`` and ``define_table()``), :meth:`access_ddl` (behind
+        :meth:`define_access`, with or without the table) and :meth:`_auth_variables` (behind :meth:`signup` and
+        :meth:`signin`) call it before any request.
+
+        Raises:
+            TypeError: naming the model and those fields, in declaration order (``schema.signup_excluded_refused()``).
+        """
+        excluded = cls._signup_fields_excluded()
+        if excluded:
+            raise TypeError(signup_excluded_refused(cls.__name__, excluded))
+
     @classmethod
     def _signup_primary_key(cls) -> str | None:
         """The primary key SIGNUP builds the record id from, or ``None`` for a server id.
@@ -383,15 +399,17 @@ class AuthenticatedUserMixin:
             TypeError: with ``with_table=True``, a ``TableType.USER`` model with
                 ``extra="allow"`` (its ``SCHEMAFULL`` table refuses or drops the fields the
                 model does not declare), or, for a model whose schema mode is ``SCHEMAFULL``,
-                an *overwrite* that is not a ``bool``, or a field SIGNUP writes that
-                ``Field(exclude=True)`` keeps out of ``model_dump()`` and so out of the table
-                (SurrealDB 3.x would refuse every signup, 2.x drop the value — a password hash,
-                failing every signin); the message names the model and the fields, in
-                declaration order. ``table_ddl()`` and ``define_table()`` refuse that model too.
+                an *overwrite* that is not a ``bool``; then, whatever the schema mode and
+                *with_table*, a field SIGNUP writes that ``Field(exclude=True)`` keeps out of
+                ``model_dump()``: ``update()`` and ``upsert()`` replace the record with what
+                ``model_dump()`` writes, so on any table (``SCHEMALESS``, or defined by hand)
+                they would drop the value — a password hash, failing every later signin — or
+                be refused by a required column, and a ``SCHEMAFULL`` table would not define
+                the field (SurrealDB 3.x would refuse every signup, 2.x drop the value). The
+                message names the model and the fields, in declaration order; ``table_ddl()``,
+                ``define_table()``, :meth:`signup` and :meth:`signin` refuse that model too.
                 Remove ``exclude=True`` and pass ``exclude=`` to ``model_dump()`` where you
-                serialise the model: ``update()`` and ``upsert()`` replace the record with what
-                ``model_dump()`` writes, so a table defined by hand would refuse them or drop the
-                value.
+                serialise the model.
             ValueError: an auth key naming no field of the model, an unknown hashing family or
                 duration, a primary key SIGNUP cannot bind; with ``with_table=True`` and a
                 ``SCHEMAFULL`` schema mode, a ``FLEXIBLE`` request on a kind without an object
@@ -416,11 +434,13 @@ class AuthenticatedUserMixin:
 
         statements: list[str] = []
         if with_table and cls._schemafull_access():
-            # The model table DDL's refusals, SG1 (#296) included: a column SIGNUP writes that the table would not define.
+            # The model table DDL's refusals, UX1 then SG1 included.
             table_ddl: list[str] = cls._table_ddl(overwrite, cls._access_table_clauses())  # type: ignore[attr-defined]
             statements.extend(table_ddl)
         elif with_table:
             statements.append(cls._access_table_statement(table, clause))
+        # SG1 whatever the schema mode and with_table (#299): update() and upsert() would drop what SIGNUP wrote.
+        cls._refuse_signup_fields_excluded()
 
         # The record id follows the model's primary key, because the rest of the ORM does: a
         # random id here would leave User.objects().get(email=…) addressing a record the
@@ -516,8 +536,8 @@ class AuthenticatedUserMixin:
 
         Raises:
             TypeError: see :meth:`access_ddl` — before any request, a field SIGNUP writes that
-                ``Field(exclude=True)`` keeps out of a ``SCHEMAFULL`` table included, which
-                ``define_table()`` refuses too.
+                ``Field(exclude=True)`` keeps out of ``model_dump()`` included, whatever the
+                schema mode and *with_table*.
             ValueError: see :meth:`access_ddl` — before any request.
             SurrealDbError: if the server rejects a statement. The most likely cause on
                 **SurrealDB 2.6.x** is ``with_refresh=True``: that line cannot parse
@@ -574,7 +594,12 @@ class AuthenticatedUserMixin:
         Every field named in the SIGNUP clause must be bound, or the server has no value for a
         ``$variable`` it references — so absent optional fields are sent as ``None`` explicitly
         rather than omitted.
+
+        First of all, SG1 (#299): a model with a field SIGNUP writes that ``Field(exclude=True)``
+        keeps out of ``model_dump()`` is refused, so an access defined by hand cannot leave a
+        stored record that ``update()`` or ``upsert()`` would strip of its hash.
         """
+        cls._refuse_signup_fields_excluded()
         known = set(cls._signup_fields())
         unknown = sorted(set(values) - known)
         if unknown:
@@ -926,6 +951,10 @@ class AuthenticatedUserMixin:
             instance's password field holds the **hash**, since that is what the server stores.
 
         Raises:
+            TypeError: the model has a field SIGNUP writes that ``Field(exclude=True)`` keeps
+                out of ``model_dump()`` (see :meth:`access_ddl`) — before any request, so an
+                access defined by hand cannot leave a record that ``update()`` or ``upsert()``
+                would strip of its password hash.
             ValueError: for an unknown field or a missing required one — before any request.
             SurrealDbAuthenticationError: if the server refuses the signup, or returns no
                 record for the new session (the message says how to grant the permission).
@@ -948,6 +977,7 @@ class AuthenticatedUserMixin:
         Isolation and ``bind=`` behave exactly as in :meth:`signup`, on the embedded engine too.
 
         Raises:
+            TypeError: as in :meth:`signup` — before any request.
             ValueError: for an unknown or missing field — before any request.
             SurrealDbAuthenticationError: if the credentials are refused. Both DB lines are
                 normalised here: the same wrong password surfaces as ``NotFoundError`` on 3.x

{surreal_orm_lite-0.35.0 → surreal_orm_lite-0.35.2}/src/surreal_orm_lite/model_base.py

@@ -47,7 +47,6 @@ from .schema import (
     read_table_fields,
     remove_event_statement,
     remove_view_statement,
-    signup_excluded_refused,
     table_holds_records,
     table_kind,
     table_permissions_text,
@@ -1761,9 +1760,9 @@ class BaseSurrealModel(BaseModel):
         ``FLEXIBLE`` following *clauses*' schema mode. Pure.
 
         Raises:
-            TypeError: *overwrite* is not a ``bool``; a ``TableType.USER`` model with ``extra="allow"`` (UX1); then, when
-                *clauses* are ``SCHEMAFULL``, an auth model (``AuthenticatedUserMixin``) with a field SIGNUP writes that
-                ``Field(exclude=True)`` keeps out of the columns (SG1, #296).
+            TypeError: *overwrite* is not a ``bool``; a ``TableType.USER`` model with ``extra="allow"`` (UX1); then,
+                whatever *clauses*' schema mode, an auth model (``AuthenticatedUserMixin``) with a field SIGNUP writes
+                that ``Field(exclude=True)`` keeps out of ``model_dump()`` (SG1, #296, #299).
             ValueError: see :meth:`_table_columns`.
         """
         if cls._is_view():
@@ -1774,16 +1773,15 @@ class BaseSurrealModel(BaseModel):
             raise TypeError(user_extra_refused(cls.__name__))
         schemafull = clauses.schema_mode == SchemaMode.SCHEMAFULL.value
         fields = [field_statement(table, column, overwrite=overwrite, schemafull=schemafull) for column in cls._table_columns()]
-        if schemafull:
-            # Imported here, only for a SCHEMAFULL table: model_auth sits above this module.
-            from .model_auth import AuthenticatedUserMixin
-
-            # SG1 (#296), after the other refusals: SIGNUP writes a field the columns leave out, which the SCHEMAFULL
-            # table would refuse (3.x) or drop (2.x) — checked here, as UX1 is, so that table_ddl(), define_table(),
-            # access_ddl() and define_access() refuse the same model.
-            excluded: list[str] = cls._signup_fields_excluded() if issubclass(cls, AuthenticatedUserMixin) else []
-            if excluded:
-                raise TypeError(signup_excluded_refused(cls.__name__, excluded))
+        # Imported here: model_auth sits above this module.
+        from .model_auth import AuthenticatedUserMixin
+
+        if issubclass(cls, AuthenticatedUserMixin):
+            # SG1 (#296, #299), after the other refusals, whatever the schema mode: SIGNUP writes a field model_dump()
+            # leaves out, which update() and upsert() would drop and a SCHEMAFULL table would refuse (3.x) or drop
+            # (2.x) — checked here, as UX1 is, so that table_ddl() and define_table() refuse the model access_ddl(),
+            # define_access(), signup() and signin() refuse.
+            cls._refuse_signup_fields_excluded()
         return [statement, *fields]
 
     @classmethod
@@ -1827,11 +1825,13 @@ class BaseSurrealModel(BaseModel):
         Raises:
             TypeError: *overwrite* is not a ``bool``; a ``TableType.USER`` model with ``extra="allow"`` (its table is
                 ``SCHEMAFULL``, which refuses or drops the fields the model does not declare); an auth model
-                (``AuthenticatedUserMixin``) whose declared schema mode is ``SCHEMAFULL`` with a field SIGNUP writes
-                that ``Field(exclude=True)`` keeps out of the columns (``password: str = Field(exclude=True)``), which
-                the table would refuse or drop, failing every signup or signin — ``define_access()`` refuses it too;
-                remove ``exclude=True`` (a table defined by hand would not help: ``update()`` and ``upsert()`` replace
-                the record with what ``model_dump()`` writes).
+                (``AuthenticatedUserMixin``), whatever its schema mode, with a field SIGNUP writes that
+                ``Field(exclude=True)`` keeps out of ``model_dump()`` (``password: str = Field(exclude=True)``):
+                ``update()`` and ``upsert()`` replace the record with what ``model_dump()`` writes, so they would drop
+                the password hash, failing every later signin, or be refused by a required column, and a
+                ``SCHEMAFULL`` table would not define the field — ``access_ddl()``, ``define_access()``, ``signup()``
+                and ``signin()`` refuse the model too; remove ``exclude=True`` and pass ``exclude=`` to
+                ``model_dump()`` where you serialise the model.
             ValueError: a ``FLEXIBLE`` request on a kind without an object; a computed field's expression that is not
                 SurrealQL the ORM can embed.
 
@@ -2008,8 +2008,8 @@ class BaseSurrealModel(BaseModel):
 
         Raises:
             TypeError: *overwrite* is not a ``bool``; a ``TableType.USER`` model with ``extra="allow"``; an auth model
-                whose declared schema mode is ``SCHEMAFULL`` with a field SIGNUP writes that ``Field(exclude=True)``
-                keeps out of the columns (see :meth:`table_ddl`) — before any request.
+                with a field SIGNUP writes that ``Field(exclude=True)`` keeps out of ``model_dump()``, whatever its
+                schema mode (see :meth:`table_ddl`) — before any request.
             ValueError: a ``FLEXIBLE`` request on a kind without an object; a computed field's expression that is not
                 SurrealQL the ORM can embed — before any request.
             SurrealDbError: *tx* belongs to another connection — before any request; the table is a materialized view

{surreal_orm_lite-0.35.0 → surreal_orm_lite-0.35.2}/src/surreal_orm_lite/schema.py

@@ -85,8 +85,10 @@ table's field definitions with one ``INFO FOR TABLE``, keyed by path whichever r
 definition the parser cannot read. ``table_refused()`` gives the texts of the node models' table guard (TG1–TG4),
 ``relation_table_refused()`` names ``define_table()`` when it is the caller, and ``relation_schemafull_refused()``
 refuses ``define_relation()`` of an edge model declared ``SCHEMAFULL`` with data fields, which it would not define.
-``user_extra_refused()`` and ``signup_excluded_refused()`` give the texts of UX1 and SG1, the refusals of a
-``SCHEMAFULL`` table the model table DDL checks before any request.
+``user_extra_refused()`` gives the text of UX1, the refusal of a ``SCHEMAFULL`` table the model table DDL checks before
+any request, and ``signup_excluded_refused()`` that of SG1, an auth model with a field SIGNUP writes that
+``Field(exclude=True)`` keeps out of ``model_dump()``, refused whatever its schema mode by the model table DDL, the
+access DDL, ``signup()`` and ``signin()`` (#299).
 
 The module sits low in the package: it imports neither ``model_base`` nor ``connection_manager``, so both can import
 it.
@@ -1949,16 +1951,20 @@ def user_extra_refused(model: str) -> str:
 
 
 def signup_excluded_refused(model: str, fields: Sequence[str]) -> str:
-    """The refusal of an auth model whose ``SCHEMAFULL`` table would leave out *fields* (SG1, #296): SIGNUP writes
-    them, ``Field(exclude=True)`` keeps them out of ``model_dump()`` and so out of the columns the model table DDL
-    defines — in ``table_ddl()``, ``define_table()`` and ``define_access()`` alike. Pure."""
+    """The refusal of an auth model with *fields* (in declaration order) that SIGNUP writes and
+    ``Field(exclude=True)`` keeps out of ``model_dump()`` (SG1): ``update()`` and ``upsert()`` replace the stored record
+    with what ``model_dump()`` writes, whatever the table's schema mode, so they drop them or a required column refuses
+    them (#299), and a ``SCHEMAFULL`` table defined from the model has no column for them (#296). ``table_ddl()``,
+    ``define_table()``, ``access_ddl()``, ``define_access()``, ``signup()`` and ``signin()`` raise it before any
+    request. Pure."""
     names = ", ".join(repr(name) for name in fields)
     pronoun = "it" if len(fields) == 1 else "them"
     return (
-        f"{model}: SIGNUP writes {names}, but Field(exclude=True) keeps {pronoun} out of model_dump() and so out of the "
-        f"SCHEMAFULL table that table_ddl(), define_table() and define_access() define for the model; that table would "
-        f"refuse {pronoun} (SurrealDB 3.x) or drop {pronoun} (2.x), so no signup or signin would work. Remove "
-        f"exclude=True and leave {pronoun} out where you serialise the model instead (model_dump(exclude={{{names}}})): "
-        f"update() and upsert() replace the record with what model_dump() writes, so even over a table defined by "
-        f"hand they would be refused or drop {pronoun}."
+        f"{model}: SIGNUP writes {names}, but Field(exclude=True) keeps {pronoun} out of model_dump(), and update() and "
+        f"upsert() replace the stored record with what model_dump() writes, whatever the table's schema mode: they "
+        f"would drop {pronoun} (a password hash: every later signin fails) or be refused by a required column. A "
+        f"SCHEMAFULL table defined from the model has no column for {pronoun} either (SurrealDB 3.x refuses the signup, "
+        f"2.x drops {pronoun}). Remove exclude=True and leave {pronoun} out where you serialise the model instead "
+        f"(model_dump(exclude={{{names}}})); until then table_ddl(), define_table(), access_ddl(), define_access(), "
+        f"signup() and signin() refuse {model}."
     )