[qiaoyuang]

All

• Update AGP's version to 9.5.1
• Update Gradle's version to 9.9.0
• Update kotlinx.serialization's version to 1.12.0

sqllin-dsl

• Fix: the default lookasideSlotSize and lookasideSlotCount of DSLDBConfiguration disabled SQLite's lookaside memory allocator on Kotlin/Native and on Android 9 and higher, as those of DatabaseConfiguration did; they are now -1, see sqllin-driver
• Fix: on the JVM and Kotlin/Native, a blocking database { } scope on another thread could take the TEMP table and triggers that count the changes of observed queries with it, as its transaction can be open while they are created, the connection being locked for each statement rather than for a transaction: its rollback removed them, so the next write failed with "no such table", and once another table was observed, the changes of the table they belonged to were no longer counted. The tracker now creates them again where they are gone, and counts a change of their tables. A failure to tell the observed queries of a change no longer takes the place of the failure of the statement that made it. The guide to observed queries and the documentation of Database#invoke and Database#observe now say to write through suspendedScope while queries are observed, as they run on another thread, and that a blocking scope isn't serialized with them
• Fix documentation: the example of the guide to concurrency safety called database suspendScope { }, which doesn't exist, in a function that wasn't a suspend one; it is database suspendedScope { }, in a suspend function
• Fix: INSERT failed with near ")": syntax error when the primary key that the database assigns, a Long? property annotated with @PrimaryKey, was the last property of the class: as INSERT leaves such a key out, the column list kept a trailing comma, and the VALUES tuple was never closed. A key declared before another property wasn't affected, and neither were INSERT_WITH_ID, INSERT_OR_IGNORE and INSERT_OR_REPLACE, which write the key
• Fix documentation: examples that didn't compile. The READMEs and the query guide called SelectStatement.getResult(), which doesn't exist, rather than getResults(); the guide to getting started imported DSLDBConfiguration from com.ctrip.sqllin.driver rather than com.ctrip.sqllin.dsl, and, in English, the annotation NoCase, which doesn't exist, rather than CollateNoCase; and the guide to modifying the database declared an autoIncrement primary key as Long = 0, which the processor rejects, rather than Long? = null
• Fix: a clause appended to a statement replaced the last statement of the scope, rather than the one it completes, when another statement had been built since, as when a statement is held in a variable and completed later: the other statement didn't run, and the incomplete one still did. So an UPDATE held as val update = table UPDATE SET { ... }, followed by a SELECT and then completed with update WHERE (...), updated every row of the table, and the SELECT returned nothing. WHERE also added its parameters to those of the UPDATE without it. A clause now replaces the statement it completes, wherever it is, and appending one to a statement that a clause was already appended to, or that became part of another one, as a subquery, a compound SELECT or EXPLAIN_QUERY_PLAN does, fails with an IllegalStateException before any statement of the scope runs, rather than replacing another statement
• Fix: a transaction in another one, which the documentation of DatabaseScope says can be nested, ended the outer one when it ended, since 2.0.0 at least: the statements after it in the outer block weren't in the transaction, so they ran on their own, and when one of them failed, those before it weren't rolled back; a second transaction in the outer one began a transaction of its own, in its own mode. beginTransaction() and endTransaction() now count how deeply transactions are nested, and only the outermost endTransaction() ends the transaction, so the statements of an inner transaction and those after it are the outer one's, which commits or rolls back all of them. As the fix is in these two functions, rather than in the inline transaction { }, it also applies to code compiled against an earlier version, and to nested calls of the two functions
• Fix: on Android 13 and higher, PRAGMA_FOREIGN_KEYS(flag) didn't apply to the INSERT, UPDATE and DELETE statements whose SQL had run before, which kept checking foreign keys or not as before, such as after a migration that turned them off and on again; see sqllin-driver
• Fix: on Kotlin/Native and on Android 8.1 and lower, the journalMode of DSLDBConfiguration, WAL by default, didn't take effect, since 1.2.0; see sqllin-driver
• Breaking change: removed the joins written as clauses of SELECT, which 2.5.0 announced would be removed: the functions CROSS_JOIN, JOIN, INNER_JOIN, NATURAL_JOIN, NATURAL_INNER_JOIN, LEFT_OUTER_JOIN and NATURAL_LEFT_OUTER_JOIN that took relations as arguments, the SELECT and SELECT_DISTINCT that took what they returned, and the types BaseJoinClause, JoinClause, NaturalJoinClause, JoinStatementWithoutCondition and JoinSelectStatement, with the ON, USING, WHERE, GROUP_BY, ORDER_BY and LIMIT that took them. To migrate, write the join as a join of relations: table SELECT INNER_JOIN<R>(other) USING column becomes (table INNER_JOIN other USING column) SELECT X<R>(). Its result type is checked against the joined relations when the statement is built, so a type that reads a column two relations have has to select it with AS, and one that reads a column an outer join can leave NULL has to make its property nullable. The guide to advanced queries describes the migration
• New experimental DSL API: a join can start with its first relation, as in (PersonTable INNER_JOIN BookTable ON (PersonTable.id EQ BookTable.authorId)) SELECT X<R>(), without FROM, with each join operator: INNER_JOIN, LEFT_OUTER_JOIN, RIGHT_OUTER_JOIN, FULL_OUTER_JOIN, CROSS_JOIN and the NATURAL joins. FROM(relation) still starts one too
• Breaking change: removed the UNION {} and UNION_ALL {} blocks, and the DatabaseScope#beginUnion, createUnionSelectStatement and endUnion functions they used, which 2.5.0 deprecated for bugs that wouldn't be fixed: a union of projections, result columns or joins failed with a ClassCastException, and a nested block was flattened into the SQL, which changed its meaning. To migrate, use the infix operators: UNION { a; b } becomes (a) UNION (b), and UNION_ALL { a; b } becomes (a) UNION_ALL (b). The guide to advanced queries describes it
• New experimental API: table version tokens, which tell a reader when the tables it read change, such as a PagingSource that invalidates itself. Database#versioned { } runs a scope of SELECTs, and returns its result with a TableVersions token of the versions of the tables they read, captured under the lock that they run under, after the tables are tracked, so that no change after them is missed; a scope that writes is rejected. Database#awaitChange(token) suspends until a statement run through the database changes one of those tables, and Database#onChange(token) { } registers a callback that runs once, after the writing scope releases the lock, on the thread that wrote, and returns an AutoCloseable that closes the registration, or null when the token is already stale, as it registers before it checks. Tokens combine with +, which takes the earlier version of a table that both read, and rejects the tokens of another Database
• New experimental DSL API: the other conflict resolutions of a statement: INSERT_OR_ABORT, INSERT_OR_FAIL and INSERT_OR_ROLLBACK, for SQL syntax INSERT OR ABORT, INSERT OR FAIL and INSERT OR ROLLBACK, which take objects, expressions, DEFAULT_VALUES and a SELECT, as INSERT does, and write the primary key, as INSERT_OR_IGNORE and INSERT_OR_REPLACE do; and UPDATE_OR_ABORT, UPDATE_OR_FAIL, UPDATE_OR_IGNORE, UPDATE_OR_REPLACE and UPDATE_OR_ROLLBACK, for UPDATE OR .... A statement's resolution takes the place of the conflict clause of a constraint, which onConflict declares. The guide to modifying the database describes them in a new section
• New experimental DSL API: transaction(mode) { }, which begins the transaction in a TransactionMode of sqllin-driver, for SQL syntax BEGIN DEFERRED, BEGIN IMMEDIATE and BEGIN EXCLUSIVE, rather than IMMEDIATE, the mode of transaction { }. A transaction in another one keeps the outer one's mode
• New experimental DSL API: INDEXED_BY and NOT_INDEXED, for SQL syntax INDEXED BY and NOT INDEXED, which make a statement look its rows up through an index, or none, rather than through the one SQLite's query planner chooses: (PersonTable INDEXED_BY "idx_person_name") SELECT WHERE(...) and PersonTable.NOT_INDEXED DELETE WHERE(...). The IndexedTable they return is read by a SELECT, joins included, and written by UPDATE, the UPDATE_OR_ ones and DELETE, but not by INSERT, which SQL doesn't allow, which is checked at compile time
• New experimental DSL API: EXPLAIN_QUERY_PLAN(select), for SQL syntax EXPLAIN QUERY PLAN, which tells how SQLite would run a SELECT without running it: which tables it scans, which indexes it searches, and where it sorts with a temporary B-tree. Any SELECT can be planned, joins, subqueries and compound ones included; it becomes part of the statement, and is planned with its parameters. The QueryPlanStatement it returns gives, once the scope has run, a QueryPlan: its steps, each with its detail and its children, the details of all of them, and a toString() that writes them as a tree, as the sqlite3 shell does. The details are SQLite's own text, which differs between SQLite versions, and a SQLite older than 3.24.0, as Android's before API 30, lists the steps without children; the plan is read by the columns SQLite returns, so the same on every platform, without the version of SQLite. The guide to advanced queries describes it in a new section
• New experimental DSL API: the PRAGMAs that check the database, read its schema and what the SQLite has, checkpoint the WAL, read the size and the header of the file, and set how statements run: PRAGMA_INTEGRITY_CHECK(maxErrors) and PRAGMA_QUICK_CHECK(maxErrors), which return the problems found, or an empty list rather than SQLite's ok; PRAGMA_FOREIGN_KEY_CHECK(), of all tables or of one; PRAGMA_FOREIGN_KEYS(), which reads what PRAGMA_FOREIGN_KEYS(flag) sets; PRAGMA_TABLE_INFO(table), of a table, a view or a name, PRAGMA_INDEX_LIST(table), PRAGMA_INDEX_XINFO(index) and PRAGMA_FOREIGN_KEY_LIST(table); PRAGMA_WAL_CHECKPOINT(mode), which throws an IllegalStateException inside a transaction, where SQLite can't checkpoint; PRAGMA_PAGE_COUNT(), PRAGMA_FREELIST_COUNT() and PRAGMA_PAGE_SIZE(); PRAGMA_DEFER_FOREIGN_KEYS(flag), which throws an IllegalStateException outside a transaction, as SQLite turns it off when one ends; PRAGMA_RECURSIVE_TRIGGERS(flag), PRAGMA_LEGACY_ALTER_TABLE(flag), which Android's SQLite turns on by default, and PRAGMA_IGNORE_CHECK_CONSTRAINTS(flag); PRAGMA_APPLICATION_ID() and PRAGMA_APPLICATION_ID(id); PRAGMA_AUTO_VACUUM() and PRAGMA_AUTO_VACUUM(mode), which VACUUM applies to a database that has tables, while PRAGMA incremental_vacuum is left out, as it removes a page each time it returns a row, which has no columns, and sqlite-jdbc runs such a statement only as far as its first row; PRAGMA_COLLATION_LIST() and PRAGMA_DATABASE_LIST(); and, marked with @PlatformDependentSQLiteAPI, PRAGMA_TABLE_XINFO(table), which needs SQLite 3.26.0, Android API 30, PRAGMA_FUNCTION_LIST(), PRAGMA_MODULE_LIST() and PRAGMA_PRAGMA_LIST(), which need SQLite 3.30.0, Android API 31, PRAGMA_TABLE_LIST(), which needs SQLite 3.37.0, Android API 34, PRAGMA_INTEGRITY_CHECK(table) and PRAGMA_QUICK_CHECK(table), which need SQLite 3.33.0, Android API 34, below which they check the whole database, and PRAGMA_COMPILE_OPTIONS(), which Android's SQLite is built without. A PRAGMA that SQLite lacks is ignored rather than failing, so those that only newer versions have check the columns of the rows SQLite returns, and throw an IllegalStateException that tells what they need, rather than return nothing, without asking SQLite for its version. auto_vacuum and page_size are read in a transaction of their own outside one, as SQLite takes them from what the connection last read of the header of the file, which on Android 13 and higher may be a connection that reads, which would tell the mode before the last VACUUM. A PRAGMA that reads returns a PragmaStatement, whose getResults() returns, once the scope has run, a list of ColumnInfo, IndexInfo, IndexColumn, ForeignKeyInfo, ForeignKeyViolation, RelationInfo, DatabaseInfo or FunctionInfo, a CheckpointResult, an AutoVacuum, or a value. Each PRAGMA runs as a query or not, as it returns rows or not, which neither Android's framework nor sqlite-jdbc would otherwise run, and a PRAGMA changes no table, so it can be in a versioned read. The guide to modifying the database describes them in a new section
• New experimental DSL API: @CollateRTrim, for SQL syntax COLLATE RTRIM in a column's definition, which compares the column's values ignoring the spaces at their ends, as its UNIQUE constraint and indexes do, while storing them as they are written; a property can't have it and @CollateNoCase both, which the processor reports, as it does on a property that isn't a String or a Char. A column without either compares its values as the BINARY collation does, which a column has by default. And the COLLATE operator, which 2.5.0 added for conditions and ORDER BY, gives a column of an index its collation, as in PersonTable.CREATE_INDEX("idx_person_name_nocase", PersonTable.name COLLATE NOCASE), for SQL syntax CREATE INDEX ... ON person(name COLLATE NOCASE), also with an order, as (PersonTable.name COLLATE NOCASE) to DESC, which the queries that compare by that collation use. The guides to getting started and to modifying the database describe them
• New experimental DSL API: ORDER_BY, LIMIT and OFFSET after a DELETE or an UPDATE, with its WHERE or without, which only write the first rows in an order, or as many as LIMIT says, as in PersonTable DELETE WHERE(PersonTable.age LT 18) ORDER_BY (PersonTable.age to ASC) LIMIT 10, for SQL syntax DELETE ... ORDER BY ... LIMIT ... and UPDATE ... ORDER BY ... LIMIT .... SQLite only takes them when it is built with SQLITE_ENABLE_UPDATE_DELETE_LIMIT, which Android's SQLite isn't, and then turns them into a subquery of the rowids of the rows they choose, so SQLlin writes that subquery itself, which every platform runs, with the same query plan: DELETE FROM person WHERE rowid IN (SELECT rowid FROM person WHERE person.age<? ORDER BY person.age ASC LIMIT 10). It can be in the body of a trigger too, where SQLite's own syntax isn't allowed; INDEXED_BY and NOT_INDEXED decide how the subquery looks the rows up; a table with a column named rowid reads its rowid as _rowid_ or oid; and a negative LIMIT is none, so that OFFSET keeps the first rows, as in ORDER_BY (time to DESC) LIMIT -1 OFFSET 100. ORDER_BY has to be followed by LIMIT, as SQLite says: a scope where it isn't throws an IllegalArgumentException before any of its statements runs, as does CREATE_TRIGGER for a trigger whose body has one. The guide to modifying the database describes them in a new section
• Breaking change: UPDATE ... WHERE returns a WhereUpdateDeleteStatement, which ORDER_BY and LIMIT can follow, rather than the String of its SQL, which its sqlStr is; and DELETE X and DELETE WHERE(...), of a table and of an IndexedTable, return one too, rather than Unit, which changes no source but code compiled against an earlier version, which has to be compiled again
• New API: @InternalSQLlinAPI, which marks the APIs of sqllin-dsl that only SQLlin's other modules use, as sqllin-dsl-paging loads its pages through, which apps shouldn't use, as they may change in any version
• Breaking change, fix: a property whose serializer isn't the default one of its type, as an enum whose class declares a serializer that stores its name, or a property annotated with @Serializable(with = ...), was written by that serializer in INSERT, but compared in conditions, and set in SET {}, as its type is by default, as the ordinal of an enum entry, in a column of the type of its Kotlin type, INT for an enum: a condition didn't match the values stored, and a row that SET {} changed couldn't be read. Such a property is now a column converted by its serializer, see below: code that names the type of its element, as ClauseEnum<Status>, or uses an operator of ClauseString or ClauseNumber on it, as LIKE or +, has to change, and its operators, which are experimental, need an opt-in. A table created before keeps the type of its column, which holds values of any type in SQLite, so it needs no migration. An enum with its default serializer, or serialized contextually, is still stored as its ordinal
• Fix: a SELECT whose results weren't read kept its cursor, and its statement, open: its tables couldn't be dropped meanwhile, failing with database table is locked, and on Kotlin/Native the connection stayed open after close(), as sqlite3_close_v2 waits for the statements to end, holding the database file, which Windows then couldn't delete. A SELECT now reads its rows when its scope runs it, under the scope's lock and in its transaction, so that an error decoding them is thrown by the scope, and getResults() returns them
• New experimental DSL API: columns of the types that SQLite doesn't store, whose serializers convert their values to those of a column: kotlin.uuid.Uuid, kotlin.time.Instant and kotlin.time.Duration, with their built-in serializers, value classes, types whose classes declare their serializers, as those of kotlinx-datetime do, and any type given a serializer with @Serializable(with = ...) on the property, on the use of its type or in a type alias, or by @file:UseSerializers, as a List stored as JSON. The serializer is the converter: the column has the type of the value it stores, which CREATE and ALTER_ADD_COLUMN compute from it, and the column's element, a ClauseConverted<T>, converts the values of its conditions with it, EQ, NEQ, LT, LTE, GT, GTE, IN, of values and of a subquery, BETWEEN, IS and ISNOT, as SET {} converts the values it assigns. literal(value, serializer) is a literal of such a type. A comparison other than an equality, and ORDER_BY, compare the stored values, which are in the order of the Kotlin values only if the serializer keeps it, as the ISO-8601 strings of the built-in serializer of Instant aren't. A serializer that encodes a structure, as the generated one of a data class, fails CREATE. See the guide to getting started
• New API: the protected Table#columnType(elementIndex, collation) and Table#appendConverted(...) of SetClause, which the tables that sqllin-processor generates call for the columns converted by their serializers

sqllin-dsl-paging

• New module, com.ctrip.kotlin:sqllin-dsl-paging, on every platform of sqllin-dsl, which depends on androidx.paging's paging-common 3.5.3: new experimental API Database#pagingSource(context) { }, which returns androidx.paging's PagingSource of the rows of the SELECT it builds, loaded a page at a time by their offsets, as Room's LimitOffsetPagingSource does. A page is SELECT * FROM (select) LIMIT ... OFFSET ..., so the SELECT can have a WHERE, a join or compound operators; the first page also counts the rows, so that each page tells how many rows are before and after it, which placeholders show, and a refresh past the last row loads the last ones. The keys are offsets at the borders between pages, so that two pages never share a row, and a page after the first row can always prepend the rows above it, as after a RemoteMediator invalidates the source; a refresh starts half the initial load before the row last read, also without placeholders, whose positions don't count the rows before the first page. It is built on the table version tokens of sqllin-dsl: it registers with Database#onChange from its first page, weakly, so that a source its Pager drops can still be collected, and closes the registration when it is invalidated otherwise; a change of a table the SELECT reads invalidates it, and a page that reads rows changed since the first one is LoadResult.Invalid(), with which the source is invalid, also for a TestPager or another caller of load; a source invalidated before it loads reads nothing. Pages load in Dispatchers.IO by default. The guide to advanced queries describes it, and the guide to getting started its dependency

sqllin-driver

• Update sqlite-jdbc's version to 3.54.1.0
• Fix: the default lookasideSlotSize and lookasideSlotCount of DatabaseConfiguration, 0, which its documentation said left SQLite's default configuration, disabled SQLite's lookaside memory allocator on Kotlin/Native and on Android 9 and higher, as sqlite3_db_config and setLookasideConfig take 0 to disable it, while the JVM and lower versions of Android kept SQLite's default configuration. Their default is now -1, which leaves SQLite's default configuration on every platform, and 0 still disables the allocator. The guides to getting started now say so, and that sqlite-jdbc doesn't support sqlite3_db_config(), rather than sqlite3_config()
• Fix: on Android, busyTimeout didn't take effect, so SQLite waited 2500 ms, as the framework sets it, for a lock that another connection held. On Android 9 and higher, it was given to SQLiteDatabase.OpenParams.Builder#setIdleConnectionTimeout, which is deprecated and means another thing, how long a connection may be idle before the framework closes it, and which SQLiteOpenHelper drops anyway. busyTimeout is now set with PRAGMA busy_timeout: from Android 13 on, on every connection of the database, as one in WAL mode reads through several, and below, on its only connection. The guides to getting started listed busyTimeout, and in Chinese journalMode, among the parameters that only work on Android 9 and higher; only inMemory, lookasideSlotSize and lookasideSlotCount do
• Fix: transactions began differently on each platform, DEFERRED on the JVM and Kotlin/Native and EXCLUSIVE on Android, so on the JVM and Kotlin/Native, a transaction that read before it wrote failed at once with "database is locked" while another connection wrote, as SQLite doesn't wait for busyTimeout there, where waiting could deadlock. Transactions now begin IMMEDIATE on every platform, taking the write lock at once, for which SQLite waits as long as busyTimeout. On Android, it is what EXCLUSIVE did in WAL mode, and in DELETE mode, other connections can now read until the transaction commits. On the JVM and Kotlin/Native, a read-only connection begins a deferred transaction, as it can't take the write lock. The JVM driver begins and ends transactions with SQL rather than by leaving and entering auto-commit mode, as sqlite-jdbc then begins another transaction of the configured kind at once, which an IMMEDIATE one couldn't while another connection wrote
• Fix: when SQLite rolled a transaction back itself, as it does for a constraint with ON CONFLICT ROLLBACK, which onConflict = OnConflict.ROLLBACK declares, for a trigger's RAISE(ROLLBACK) and for some I/O errors, ending the transaction failed too, as no transaction was active, and that failure took the place of the one that made SQLite roll it back, in withTransaction and so in the DSL's transaction { }. The failure that made SQLite roll it back is now thrown, with the failure to end the transaction added to it as a suppressed exception
• Fix: on Android 13 and higher, execSQL("PRAGMA foreign_keys = ON"), and OFF, and PRAGMA recursive_triggers, legacy_alter_table and ignore_check_constraints, didn't apply to the statements whose SQL had run before, which kept checking foreign keys or not, and firing triggers recursively or not, as before. A database in WAL mode has several connections there, and the framework only prepares such a PRAGMA on the connection that writes, stepping it on one that reads, as sqlite3_stmt_readonly() reports it doesn't write; SQLite changes the setting when it prepares the PRAGMA, but only expires the statements the connection has compiled when it steps it, so those the connection that writes had cached kept the setting they were compiled with. These PRAGMAs now run on every connection of the database, those opened later included, with execPerConnectionSQL, outside a transaction, and on the connection of the transaction inside one, where SQLite ignores a change of foreign_keys, as on the other platforms. Before Android 13, a database that SQLlin opens has a single connection, which wasn't affected
• Fix: on Kotlin/Native and on Android 8.1 and lower, journalMode didn't take effect, since 1.2.0: a database stayed in the journal mode it was in, DELETE for a new one on Kotlin/Native and that of the framework on Android, rather than that of the configuration, WAL by default. SQLlin set it there with the PRAGMA, as a query, whose cursor it never read, and a query there only runs as its cursor is read. The row it returns is now read. A connection that is read-only, as one that isReadOnly opens where the file can't be written, keeps the mode the file is in, as SQLite writes WAL mode to the header of the file
• New API: TransactionMode, DEFERRED, IMMEDIATE or EXCLUSIVE, which DatabaseConnection#beginTransaction(mode) and withTransaction(mode) { } begin a transaction in, rather than IMMEDIATE, the mode of beginTransaction(). EXCLUSIVE also keeps other connections from reading in DELETE journal mode, and DEFERRED takes no lock until the transaction reads or writes; Android's framework can't begin a deferred transaction that writes, so on Android DEFERRED begins an IMMEDIATE one. The new beginTransaction has a default implementation, which only begins an IMMEDIATE transaction, so a DatabaseConnection implemented outside SQLlin still compiles

sqllin-processor

• Fix: only the Java classes of the processor had a JVM target, 21, so its Kotlin classes were compiled for the JDK that ran the build, as for Java 25 by JDK 25, which a KSP run on an older JDK can't load, failing with UnsupportedClassVersionError. The processor is now built with the JVM toolchain of the other modules, JDK 21, which its Kotlin classes target as well
• Support the properties whose serializers convert their values, see sqllin-dsl: the processor finds the serializer that kotlinx.serialization writes a property with, given on the property, on the use of its type or in a type alias, by @file:UseSerializers or by its class, and generates a ClauseConverted element with it. The objects of the tables that have such columns opt in to ExperimentalDSLDatabaseAPI, and to the markers that the @OptIns of the entity's class, properties and file give, as the type of a column can need, as Uuid does. A property of a type that no column can hold, as a collection, a class serialized as a structure or a type serialized contextually, is still an error, whose message says how to give it a serializer that stores one value
• Fix: an enum, or any property, with a serializer that isn't the default one of its type, was compared and set as its type is by default; see sqllin-dsl
• Fix: the object generated for a @DBRow or @DBView class annotated with an opt-in marker, as @ExperimentalUuidApi, which requires the uses of the class to opt in, didn't opt in to it, so it didn't compile; it now opts in to the markers that the class, its properties and its file are annotated with

🤖 Generated with Claude Code