[kac-axelor]

Align CRUD type operations for consistent BigDecimal handling

Problem

The ORM CRUD types had inconsistent handling of BigDecimal fields:

// ✅ Works - string accepted
await client.country.create({ data: { population: "138.50" } });
await client.country.find({ where: { population: { gt: "15.00" } } });

// ❌ Type error - string rejected
await client.country.update({
  data: { id: 1, version: 1, population: "138.50" }
});

// ❌ Type error - string rejected in bulk
await client.country.updateAll({
  set: { population: "138.50" }
});

Solution

1. Extract Shared Type (structural symmetry)

Created LeafArg<T> type to eliminate copy-paste logic and prevent future drift:

• Handles BigDecimal special-casing: accepts string | number | bigint | BigDecimal
• Applies AllowNull for nullable fields
• Used consistently across CreateArg, UpdateArg, and BulkSetArg

2. Extend to Bulk Operations

Updated BulkSetArg<T> to use LeafArg<T>, bringing parity with standard update operations

3. Comprehensive Test Coverage

• Update operations: test all supported types (string, number, bigint, BigDecimal instance, null)
• Bulk operations: mirror the update test pattern with chained operations
• Ensures the type contract is locked and prevents regressions

Changes

• src/client/types/crud.ts: Extract LeafArg<T>, apply to CreateArg, UpdateArg, BulkSetArg
• src/test/client-bigdecimal.test.ts: Comprehensive update test covering all value types
• src/test/client-bulk.test.ts: Bulk operation test mirroring update test pattern

[ame-axelor]

Fix looks correct — the new branch faithfully mirrors CreateArg's BigDecimal handling and resolves the asymmetry. Before merging, could you address a few things?

1. Add a test. src/test/client-bigdecimal.test.ts exercises create with string/number values but never update. A small addition there would lock the contract in and catch any future regression:

   await client.country.update({
     data: { id: country.id, version: country.version, population: "200.00" },
   });

2. Extract a shared leaf alias to prevent drift. The leaf tails of CreateArg and UpdateArg are now copy-pasted — if another special-cased leaf type lands later (Date, Buffer, etc.), it's easy to update one and forget the other. Something like:

   type LeafArg<T> = T extends BigDecimal
     ? AllowNull<string | number | bigint | T>
     : AllowNull<T>;

   used in both CreateArg and UpdateArg makes the symmetry structural rather than convention-based. Optional but cheap.

3. Flesh out the PR description. A one-line reproduction (e.g. "client.X.update({ data: { decimalField: '1.23' }}) failed to type-check while the equivalent create works") would help anyone reading the history later understand what broke.

No concerns about correctness or runtime impact — happy to approve once the test is in.

[kac-axelor]

All issues addressed, Let me know if further changes are required

[ame-axelor]

All previous asks addressed and then some — LeafArg<T> extracted and applied to CreateArg, UpdateArg, and BulkSetArg (catching a third asymmetry I missed), plus round-trip tests covering string/number/bigint/BigDecimal/null for both update and updateAll. PR description rewritten with clear problem and solution. Nice work.

Note: the current build failure is unrelated to this PR — it's the Node 18 / pnpm 10.19 base-branch mismatch that PR #23 is addressing. This PR is purely type-level + tests and should pass once the CI upgrade lands.