kailash 4.43.0-aarch64-linux → 4.45.0-aarch64-linux
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/README.md +33 -1
- data/lib/kailash/3.2/kailash.so +0 -0
- data/lib/kailash/3.3/kailash.so +0 -0
- data/lib/kailash/3.4/kailash.so +0 -0
- data/lib/kailash/version.rb +1 -1
- data/lib/kailash.rb +29 -1
- metadata +2 -2
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: '05967636a9f54f3bcf3a7e98338e98957d77d05f19a2df14aefdaccf395ef6f3'
|
|
4
|
+
data.tar.gz: 5adb12720cecbf530dff57dfb1c13646f0eb0ead7aaaf6f144e0b7024255693e
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: d9a5a6881fbde7a3373a95b5d1d640c48453effee3427151420624559e7da480ce0c6edeac4acaeb65bb2523178a5e4246bc1947c1a73914a6d947b033ca70fe
|
|
7
|
+
data.tar.gz: 252a84fc50cffcd0b67e0c12de9b51ffcfa4eb392dc29b1f94c9ef3e04e129dc44090329034d061bf15b85bafeeba7dba01f2028f01c3541b0f67aec048d4e93
|
data/README.md
CHANGED
|
@@ -348,11 +348,43 @@ registry.close
|
|
|
348
348
|
| `DataFlowInspector` | Schema inspection |
|
|
349
349
|
| `Migration` / `MigrationManager` | Database migration management |
|
|
350
350
|
| `SchemaCache` | In-memory schema caching |
|
|
351
|
-
| `ValidationLayer`
|
|
351
|
+
| `ValidationLayer` | Field validation: rules, named validators, `validate` |
|
|
352
|
+
| `StrictMode` | Settings object only — see the note below |
|
|
352
353
|
| `LoggingConfig` | Query logging (level, format, slow query threshold) |
|
|
353
354
|
| `ErrorEnhancer` | Enhanced error context (query, params, stack) |
|
|
354
355
|
| `DebugAgent` | Query debugging |
|
|
355
356
|
|
|
357
|
+
`ValidationLayer` is backed by `kailash_dataflow::validation::ValidationLayer`
|
|
358
|
+
(`crates/kailash-dataflow/src/validation.rs:729-918`). Register rules per model
|
|
359
|
+
and field, then get the violations back:
|
|
360
|
+
|
|
361
|
+
```ruby
|
|
362
|
+
layer = Kailash::DataFlow::ValidationLayer.new
|
|
363
|
+
layer.add_rule("User", "name", "min_length", 2) # min_length, max_length,
|
|
364
|
+
layer.add_rule("User", "status", "one_of", %w[active]) # pattern, range, one_of
|
|
365
|
+
layer.add_validator("User", "email", "email") # email, url, uuid, phone
|
|
366
|
+
layer.add_custom_rule("User", "code") { |v| v.start_with?("K") }
|
|
367
|
+
|
|
368
|
+
layer.validate("User", { "name" => "A" })
|
|
369
|
+
# => [{ "field" => "name", "rule" => "min_length", "message" => "...", "value" => "A" }]
|
|
370
|
+
layer.valid?("User", { "name" => "Alice" }) # => true
|
|
371
|
+
```
|
|
372
|
+
|
|
373
|
+
Rules fail CLOSED: a rule applied to a value whose type it cannot evaluate, and a
|
|
374
|
+
custom block that raises or returns a non-boolean, both report a violation rather
|
|
375
|
+
than a pass (`crates/kailash-dataflow/src/validation.rs:257-268`). The
|
|
376
|
+
`enable_strict_mode` / `strict_mode?` / one-argument `add_validator(name)` /
|
|
377
|
+
zero-argument `validator_count` accessors are deprecated as of #2497 and removed
|
|
378
|
+
in 5.0.0; each warns that it reaches no validation. The replacements and the
|
|
379
|
+
operator checklist are in `DEPRECATION.md`.
|
|
380
|
+
|
|
381
|
+
`StrictMode` holds three boolean settings and nothing reads them: the Ruby
|
|
382
|
+
binding does not reference `kailash_dataflow::strict`, and the class registers no
|
|
383
|
+
method that takes data or returns a verdict
|
|
384
|
+
(`bindings/kailash-ruby/ext/kailash/src/dataflow.rs:2571-2580` for the state,
|
|
385
|
+
`:4544-4571` for the registered methods). Tracked as #2587; the Python binding
|
|
386
|
+
already wires the same Rust surface.
|
|
387
|
+
|
|
356
388
|
## Value Conversion
|
|
357
389
|
|
|
358
390
|
Ruby values are automatically converted to the Rust `Value` type and back:
|
data/lib/kailash/3.2/kailash.so
CHANGED
|
Binary file
|
data/lib/kailash/3.3/kailash.so
CHANGED
|
Binary file
|
data/lib/kailash/3.4/kailash.so
CHANGED
|
Binary file
|
data/lib/kailash/version.rb
CHANGED
|
@@ -4,5 +4,5 @@ module Kailash
|
|
|
4
4
|
# Ruby gem version — kept in sync with Cargo.toml via release process.
|
|
5
5
|
# The native extension also defines Kailash::VERSION from the Rust side;
|
|
6
6
|
# this file provides a fallback before the extension is loaded.
|
|
7
|
-
GEM_VERSION = "4.
|
|
7
|
+
GEM_VERSION = "4.45.0"
|
|
8
8
|
end
|
data/lib/kailash.rb
CHANGED
|
@@ -47,7 +47,35 @@ module Kailash
|
|
|
47
47
|
# its `status` + `body` to the outgoing HTTP response. Any other
|
|
48
48
|
# exception falls through to the legacy 400 "Ruby handler raised"
|
|
49
49
|
# path for backward compatibility with S5a.
|
|
50
|
-
|
|
50
|
+
# The superclass is STATED, not inherited by accident of load order.
|
|
51
|
+
#
|
|
52
|
+
# The native extension defines this class first, as
|
|
53
|
+
# `Kailash::Nexus::NexusHandlerError < Kailash::Error`
|
|
54
|
+
# (`ext/kailash/src/nexus.rs`, `define_error`), and the `require` at the top
|
|
55
|
+
# of this file runs before this block -- so a bare `class NexusHandlerError`
|
|
56
|
+
# REOPENS that exception class and everything works. It works because of the
|
|
57
|
+
# ordering, and nothing said so.
|
|
58
|
+
#
|
|
59
|
+
# If that ordering ever changed, a bare reopen would silently create a NEW
|
|
60
|
+
# class inheriting `Object`, and the feature would stop working at two
|
|
61
|
+
# separate points. Measured on Ruby 3.3.11 against the same class body
|
|
62
|
+
# evaluated without the extension loaded:
|
|
63
|
+
#
|
|
64
|
+
# superclass: Object
|
|
65
|
+
# k.new("boom", status: 422)
|
|
66
|
+
# -> ArgumentError: wrong number of arguments (given 1, expected 0)
|
|
67
|
+
# (`super(message)` reaching `Object#initialize`)
|
|
68
|
+
# raise k.new -> TypeError: exception class/object expected
|
|
69
|
+
#
|
|
70
|
+
# And the `rescue NexusHandlerError` below would not raise -- it would
|
|
71
|
+
# simply never match, which is the quieter of the two failures. Between
|
|
72
|
+
# them the documented status/body mapping would have no reachable entry
|
|
73
|
+
# point, with this comment still describing it.
|
|
74
|
+
#
|
|
75
|
+
# Naming the superclass turns that into a loud failure at load: a
|
|
76
|
+
# `NameError` if the extension has not defined `Kailash::Error` yet, or a
|
|
77
|
+
# `TypeError: superclass mismatch` if it ever defines this class differently.
|
|
78
|
+
class NexusHandlerError < ::Kailash::Error
|
|
51
79
|
attr_reader :status, :body
|
|
52
80
|
|
|
53
81
|
def initialize(message = nil, status: 500, body: nil)
|
metadata
CHANGED
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: kailash
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 4.
|
|
4
|
+
version: 4.45.0
|
|
5
5
|
platform: aarch64-linux
|
|
6
6
|
authors:
|
|
7
7
|
- Kailash Authors
|
|
8
8
|
autorequire:
|
|
9
9
|
bindir: bin
|
|
10
10
|
cert_chain: []
|
|
11
|
-
date: 2026-
|
|
11
|
+
date: 2026-08-28 00:00:00.000000000 Z
|
|
12
12
|
dependencies:
|
|
13
13
|
- !ruby/object:Gem::Dependency
|
|
14
14
|
name: rake-compiler
|