test: declare table fields with @Field and @Relation decorators in fixtures

[Upd4ting]

Summary

• Add @Field(...) decorators to every column of the table fixtures across the 11 test files (components, routes, integration)
• Add @Relation(...) on fixture fields referencing another fixture's _id (e.g. Book.authorId, Order.customerId, OrderItem.orderId/productId, Device.group_id)
• Bump @antelopejs/interface-database-decorators ^0.1.3 → ^0.1.4 (first version exporting Relation)
• No assertion or test behavior changed; _id and @Localized fields stay non-decorated, matching the interface-database-decorators reference tests

Test plan

pnpm test → 73 passing, 0 failing (same as baseline); pnpm run lint OK

Note: requires purging .antelope/cache locally after the dependency bump (documented project procedure) — the cached @antelopejs/database-decorators module embedded interface 0.1.1 without Relation.

https://claude.ai/code/session_016dBZTZJnv6S9vU2jfzeUSK

Greptile Summary

This PR annotates all fixture table classes across 11 test files with @Field(...) and @Relation(...) decorators, and bumps @antelopejs/interface-database-decorators from ^0.1.3 to ^0.1.4 to pick up the newly exported Relation decorator. No test assertions are changed.

• @Field(type) is added to every physical column (excluding _id and @Localized fields), using the correct type tokens — "string", "number", "date", "boolean", and ["string"] for arrays.
• @Relation({ to: () => TargetClass }) is applied to every foreign-key field (e.g. Book.authorId, Order.customerId, OrderItem.orderId/productId, Device.group_id), consistently placed after @Field and after any @Index.
• The lockfile also picks up patch bumps for acorn, ufo, and yaml as transitive updates.

Confidence Score: 4/5

Mechanical decorator additions to test fixtures with no changes to test assertions or production code; all 73 tests reportedly pass.

The change is confined to test fixtures and a minor dependency bump. The only deviation from the pattern is that Post.authorId is typed string | null but decorated with @field("string") without a nullability marker, which may leave the schema metadata slightly inaccurate if the decorator library supports expressing nullability.

src/tests/components/modifier_key.test.ts — the only file where a nullable field (string | null) receives @field("string") without any nullable option.

Important Files Changed

Filename	Overview
package.json	Bumps @antelopejs/interface-database-decorators from ^0.1.3 to ^0.1.4 to get the Relation export; no other production changes.
pnpm-lock.yaml	Lockfile updated to reflect the decorator package bump and a handful of transitive patch-level upgrades (acorn, ufo, yaml).
src/tests/components/modifier_key.test.ts	Adds @field("string") and @relation to Post.authorId, but the TypeScript type is string
src/tests/components/computed.test.ts	Correctly adds @field("string") to Group.name, and @Index/@Field/@relation in consistent order on Device.group_id and @field on Device.label.
src/tests/components/foreign_joined.test.ts	Adds @field and @relation to authorId (Book) and book (Shelf) consistently; Author.name gets @field("string").
src/tests/components/joined.test.ts	Adds @field decorators for all Author/Book columns and @relation on Book.authorId; types match Field arguments throughout.
src/tests/components/access_control.test.ts	Adds @field decorators to User fixture fields; types align correctly (string/number).
src/tests/components/listable.test.ts	Comprehensive @field additions across Product fixture (string, number, date); all type arguments match TypeScript annotations.
src/tests/components/mandatory.test.ts	@field decorators added to all Order fixture fields; types are correct.
src/tests/components/per_action_access.test.ts	@field decorators added to User fixture; types match TypeScript annotations.
src/tests/components/validator.test.ts	@field decorators added to Product fixture, including @field(["string"]) for the tags array; all correct.
src/tests/index/routes.test.ts	@field decorators added to User fixture; types align with TypeScript annotations.
src/tests/integration.test.ts	Largest change — @field and @relation applied across Customer, Product, Order, and OrderItem fixtures; array/date/boolean types correctly annotated.

Entity Relationship Diagram

%%{init: {'theme': 'neutral'}}%%
erDiagram
    Customer {
        string _id PK
        string email
        string firstName
        string lastName
        date registrationDate
        boolean isActive
        number loyaltyPoints
    }
    Product {
        string _id PK
        string sku
        string name
        number price
        boolean isActive
        date createdAt
    }
    Order {
        string _id PK
        string orderNumber
        string customerId FK
        string status
        number finalAmount
        date createdAt
    }
    OrderItem {
        string _id PK
        string orderId FK
        string productId FK
        number quantity
        number unitPrice
        number discount
    }
    Author {
        string _id PK
        string name
        string email
    }
    Book {
        string _id PK
        string authorId FK
        string title
    }
    Customer ||--o{ Order : "places"
    Order ||--o{ OrderItem : "contains"
    Product ||--o{ OrderItem : "included in"
    Author ||--o{ Book : "writes"

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
erDiagram
    Customer {
        string _id PK
        string email
        string firstName
        string lastName
        date registrationDate
        boolean isActive
        number loyaltyPoints
    }
    Product {
        string _id PK
        string sku
        string name
        number price
        boolean isActive
        date createdAt
    }
    Order {
        string _id PK
        string orderNumber
        string customerId FK
        string status
        number finalAmount
        date createdAt
    }
    OrderItem {
        string _id PK
        string orderId FK
        string productId FK
        number quantity
        number unitPrice
        number discount
    }
    Author {
        string _id PK
        string name
        string email
    }
    Book {
        string _id PK
        string authorId FK
        string title
    }
    Customer ||--o{ Order : "places"
    Order ||--o{ OrderItem : "contains"
    Product ||--o{ OrderItem : "included in"
    Author ||--o{ Book : "writes"

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
src/tests/components/modifier_key.test.ts:60-62
The `@Field("string")` decorator on `authorId` doesn't reflect the field's nullable TypeScript type (`string | null`). Every other `@Relation` field in this PR is non-nullable, so this is the only case where the decorator metadata and the TypeScript type diverge. If the decorator library has a way to express nullability (e.g. a second options argument), annotating it here would make the schema metadata accurate.

```suggestion
  @Field("string", { nullable: true })
  @Relation({ to: () => Author })
  declare authorId: string | null;
```

_{Reviews (1): Last reviewed commit: "test: declare table fields with @Field a..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

The @Field("string") decorator on authorId doesn't reflect the field's nullable TypeScript type (string | null). Every other @Relation field in this PR is non-nullable, so this is the only case where the decorator metadata and the TypeScript type diverge. If the decorator library has a way to express nullability (e.g. a second options argument), annotating it here would make the schema metadata accurate.

Suggested change

	@Field("string")
	@Relation({ to: () => Author })
	declare authorId: string | null;
	@Field("string", { nullable: true })
	@Relation({ to: () => Author })
	declare authorId: string | null;

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/tests/components/modifier_key.test.ts
Line: 60-62

Comment:
The `@Field("string")` decorator on `authorId` doesn't reflect the field's nullable TypeScript type (`string | null`). Every other `@Relation` field in this PR is non-nullable, so this is the only case where the decorator metadata and the TypeScript type diverge. If the decorator library has a way to express nullability (e.g. a second options argument), annotating it here would make the schema metadata accurate.

```suggestion
  @Field("string", { nullable: true })
  @Relation({ to: () => Author })
  declare authorId: string | null;
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!