v0.9.106

Merged PRs: #1144, #1147, #1149, #1151, #1152, #1164
Fixed bug: #1150

---

Note, the release contains a big new feature base-query that temporarily cannot be found in documentation

What is the new feature base-query?

Base-query is a collective term for Derived Table, CTE, and Recursive CTE in SQL.

Jimmer not only enables the functionality of Derived Table, CTE, and Recursive CTE in a strongly-typed manner but also introduces a feature absent in native SQL—a design philosophy that native SQL lacks.

In SQL, developers must first decide which columns to query in the base-query and then let the outer query select a subset of those columns.
In Jimmer, developers can make the base-query return table objects rather than expressions. The shape of these table objects is unknown. Finally, when the outer query applies a GraphQL-style data structure like Fetcher/OutputDTO to define the query shape, the outer query inversely determines which columns the inner base-query needs to fetch. This feature is called "reverse propagation of projection."
Reverse propagation of projection is the soul of Jimmer's base-query, representing the majority of the internal complexity of this feature and offering a design philosophy that native SQL simply cannot provide.

This new feature will inevitably require significant updates to the documentation. Until the documentation is fully updated, please refer to the following unit tests to understand this new functionality:

• Java

  • Derived Table: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/BaseQueryTest.java
  • CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/CteBaseQueryTest.java
  • Recursive CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/RecursiveBaseQueryTest.java

• Kotlin

  • Derived Table: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/BaseQueryTest.kt
  • CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/CteBaseQueryTest.kt
  • Recursive CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/RecursiveBaseQueryTest.kt

v0.9.105

#1132

---

Note, the release contains a big new feature base-query that temporarily cannot be found in documentation

What is the new feature base-query?

Base-query is a collective term for Derived Table, CTE, and Recursive CTE in SQL.

Jimmer not only enables the functionality of Derived Table, CTE, and Recursive CTE in a strongly-typed manner but also introduces a feature absent in native SQL—a design philosophy that native SQL lacks.

In SQL, developers must first decide which columns to query in the base-query and then let the outer query select a subset of those columns.
In Jimmer, developers can make the base-query return table objects rather than expressions. The shape of these table objects is unknown. Finally, when the outer query applies a GraphQL-style data structure like Fetcher/OutputDTO to define the query shape, the outer query inversely determines which columns the inner base-query needs to fetch. This feature is called "reverse propagation of projection."
Reverse propagation of projection is the soul of Jimmer's base-query, representing the majority of the internal complexity of this feature and offering a design philosophy that native SQL simply cannot provide.

This new feature will inevitably require significant updates to the documentation. Until the documentation is fully updated, please refer to the following unit tests to understand this new functionality:

• Java

  • Derived Table: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/BaseQueryTest.java
  • CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/CteBaseQueryTest.java
  • Recursive CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/RecursiveBaseQueryTest.java

• Kotlin

  • Derived Table: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/BaseQueryTest.kt
  • CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/CteBaseQueryTest.kt
  • Recursive CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/RecursiveBaseQueryTest.kt

v0.9.104: Kotlin API refactor for base-query

Necessary kotlin API refactor after the big refactor about the new feature base-query, include the fixing of #1133

---

What is the new feature base-query?

Base-query is a collective term for Derived Table, CTE, and Recursive CTE in SQL.

Jimmer not only enables the functionality of Derived Table, CTE, and Recursive CTE in a strongly-typed manner but also introduces a feature absent in native SQL—a design philosophy that native SQL lacks.

In SQL, developers must first decide which columns to query in the base-query and then let the outer query select a subset of those columns.
In Jimmer, developers can make the base-query return table objects rather than expressions. The shape of these table objects is unknown. Finally, when the outer query applies a GraphQL-style data structure like Fetcher/OutputDTO to define the query shape, the outer query inversely determines which columns the inner base-query needs to fetch. This feature is called "reverse propagation of projection."
Reverse propagation of projection is the soul of Jimmer's base-query, representing the majority of the internal complexity of this feature and offering a design philosophy that native SQL simply cannot provide.

This new feature will inevitably require significant updates to the documentation. Until the documentation is fully updated, please refer to the following unit tests to understand this new functionality:

• Java

  • Derived Table: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/BaseQueryTest.java
  • CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/CteBaseQueryTest.java
  • Recursive CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/RecursiveBaseQueryTest.java

• Kotlin

  • Derived Table: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/BaseQueryTest.kt
  • CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/CteBaseQueryTest.kt
  • Recursive CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/RecursiveBaseQueryTest.kt

v0.9.103: Super new feature

Base-query preview, a massive new feature

Base-query is a collective term for Derived Table, CTE, and Recursive CTE in SQL.

Jimmer not only enables the functionality of Derived Table, CTE, and Recursive CTE in a strongly-typed manner but also introduces a feature absent in native SQL—a design philosophy that native SQL lacks.

In SQL, developers must first decide which columns to query in the base-query and then let the outer query select a subset of those columns.
In Jimmer, developers can make the base-query return table objects rather than expressions. The shape of these table objects is unknown. Finally, when the outer query applies a GraphQL-style data structure like Fetcher/OutputDTO to define the query shape, the outer query inversely determines which columns the inner base-query needs to fetch. This feature is called "reverse propagation of projection."
Reverse propagation of projection is the soul of Jimmer's base-query, representing the majority of the internal complexity of this feature and offering a design philosophy that native SQL simply cannot provide.

This new feature will inevitably require significant updates to the documentation. Until the documentation is fully updated, please refer to the following unit tests to understand this new functionality:

• Java

  • Derived Table: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/BaseQueryTest.java
  • CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/CteBaseQueryTest.java
  • Recursive CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql/src/test/java/org/babyfish/jimmer/sql/tuple/RecursiveBaseQueryTest.java

• Kotlin

  • Derived Table: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/BaseQueryTest.kt
  • CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/CteBaseQueryTest.kt
  • Recursive CTE: https://github.com/babyfish-ct/jimmer/blob/main/project/jimmer-sql-kotlin/src/test/kotlin/org/babyfish/jimmer/sql/kt/query/RecursiveBaseQueryTest.kt

v0.9.99

#1104
#1108
#1109

v0.9.96(Big change)

1. weakJoins support lambda

   Jimmer has a very important capability: automatically merging conflicting table joins. This is why developers previously had to implement WeakJoin/KWeakJoin using a explicit class. Jimmer uses the class of the weak join to determine whether different weak joins conflict.

   Now, if developing applications for the JVM rather than native, users can opt for lambda-based weak joins. Jimmer will analyze the bytecode of different lambda expressions and compare whether their code logic is equivalent to determine if different weak joins conflict.

• Java example

  table.weakJoin(
      TargetTable.class, // Table type, not entity type!
      (source, target) -> source.name().eq(target.name()
  )
  

• Kotlin example

  table.weakJoin(Target::class) {
      source.name eq target.name
  }
  

2. RemoteKeyPreProvider

   Now, RemoteKeyProvider is provided, it can configurable by RedisValueBInder, RedisHashBinder or RedisCacheCreator(in spring-start)
   This interface can help you to override redis key prefix more easier, rather than override cache binder class.

v0.9.94(Important version)

Resolve Bugs

#1051, #1053,#1066, #1078, #1084, #1086

New API

Jimmer uses a lambda-style API to create immutable objects (which may be created from scratch or copied and constructed based on existing objects—this is not important). Inside the lambda, users manipulate a mutable Draft object; outside the lambda, the ultimately created object is immutable. In principle (Not absolutely), what the user obtains is a clean immutable object (not a Draft).

However, for complex programs, multiple layers of lambda contexts may be nested. Different contextual logic might exist across various code modules, which can make such nesting relationships difficult to detect at times. In essence, this nesting relationship is similar to the transaction management in an IOC framework, where such contextual nesting information is maintained by ThreadLocal.

All draft objects are resolved into immutable objects when the outermost lambda concludes. This process is referred to as resolving the draft. The outermost creation behavior returns a clean immutable object (not a draft), while inner creation behaviors directly return drafts. This default strategy is designed to optimize efficiency for complex object operations.

However, there are times when users may not know whether their creation context is the outermost layer but still need to ensure that the created object is a clean immutable object (not a draft).

Starting from version 0.9.94, the new version of the immutable object creation function includes an additional boolean parameter, resolveImmediately (defaulting to false). Users can set this parameter to true to ensure the creation function always returns a clean immutable object (not a draft), regardless of whether the current operation is the outermost creation behavior.

• Java: BookDraft.$.produce(true, draft -> { ... })
• Kotlin: Book(true) { ... }

v0.9.93

Fix #1073

v0.9.92

In the previous version, #1071 was only fixed in some scenarios, but now it has been fixed in all scenarios.

v0.9.91

#1072
#1071