You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The primary objective of this working group is to develop the next version of Panache, now known as Quarkus Data.
34
+
readme: |
35
+
<h1>Objective</h1>
36
+
<p>The main objective of this working group is to bring forth the next version of Panache.</p>
37
+
<h1>The Problem</h1>
38
+
<p>Panache is great for many things, but over time, we realised the following limitations:</p>
39
+
<ul>
40
+
<li>We have three distinct versions: Hibernate ORM, Hibernate Reactive and Mongo (blocking and reactive)</li>
41
+
<li>It is impossible to use the same entities with Hibernate ORM and Hibernate Reactive</li>
42
+
<li>Stateless sessions are not supported</li>
43
+
<li>Hibernate Processor annotations, and Jakarta Data are not supported</li>
44
+
<li>We have triplicate types such as <code>Sort</code> and <code>Order</code> between Panache, ORM and Jakarta Data</li>
45
+
<li>We have two ways to place entity query operations : on the entity itself, or in repositories</li>
46
+
<li>Entity query operations require type-system hacks which makes them less type-safe than we want with <code>var</code> and <code>for-each</code> and especially with reactive operations.</li>
47
+
</ul>
48
+
<h1>The proposed Solution</h1>
49
+
<p>We propose a new Panache version that will solve all these issues:</p>
50
+
<ul>
51
+
<li>Unify all variants in a single module, supporting blocking, reactive, stateless and stateful sessions</li>
52
+
<li>Provide an entity toplevel class for each 4 modes of operation, yet allow access to the other modes</li>
53
+
<li>Move all entity query operations from the entity class to the repository class</li>
54
+
<li>Provide a repository toplevel class for each 4 modes of operation, yet allow access to the other modes</li>
55
+
<li>Provide easy access to any type of repository by placing them as nested interfaces in the entity class, via a generated accessor on the entity metamodel class</li>
56
+
<li>Provide out of the box accessors for the 4 modes of operation repositories on the entity metamodel class</li>
57
+
<li>Support Jakarta Data and Hibernate Processor type-safe annotations</li>
58
+
<li>Optional: Support of Mongo via the coming ORM JDBC support</li>
59
+
<li>Optional: provide JD repository type alternatives for the missing three modes</li>
60
+
<li>Optional: provide a way to convert Panache 1 to Panache.Next</li>
61
+
</ul>
62
+
<h1>Definition of Done</h1>
63
+
<ul>
64
+
<li>Deliver the new Panache extension as a <code>stable</code> state (after preview/experimental versions for feedback)</li>
65
+
<li>Tests</li>
66
+
<li>Documentation</li>
67
+
<li>Codestart</li>
68
+
<li>REST Data with Panache support</li>
69
+
<li>Renarde support</li>
70
+
<li>Quarkus Insights</li>
71
+
</ul>
72
+
<h1>Scope of Work</h1>
73
+
<p>It is currently out of scope to retrofit this with the existing Panache modules. This will be a new module with no backward compatibility (although most type-unsafe operations will continue as-is, so you will be familiar with them).</p>
74
+
<h1>Organizing the Work</h1>
75
+
<h2>Communication and Transparency:</h2>
76
+
<p>This will be done via GitHub issues on the Quarkus core project.</p>
77
+
<h2>Expected Timeline:</h2>
78
+
<p>Most of the R&D and design work has been completed over the last two years. Now remains the task of merging, documenting, testing, and tweaking it until it's complete.</p>
79
+
<ul>
80
+
<li>Point of contact: @FroMage (@<strong>Stephane Epardaud</strong> on Zulip)</li>
Much of our work on Panache Next, soon to be renamed Quarkus Data, involved resolving several operation overload issues and refining Hibernate Reactive type signatures. We also enabled `StatelessSession` injection. Now, the team is tackling transaction propagation with Vert.x Context, allowing mixed `Session` and `StatelessSession`, and fixing projection failures with Kotlin value classes.
92
+
93
+
(This status update was automatically generated using AI.)
The team closed out significant work on the Vert.x 5 upgrade and migration of its core extension for Quarkus 4. New tasks include updating Vert.x configuration, reworking CI, and addressing Kafka Kerberos authentication in native mode. We're also defining OpenTelemetry trace sampling defaults and looking into extension modularity.
191
259
192
260
(This status update was automatically generated using AI.)
The primary objective of this working group is to develop the next version of Panache, now known as Quarkus Data.
197
-
readme: |
198
-
<h1>Objective</h1>
199
-
<p>The main objective of this working group is to bring forth the next version of Panache.</p>
200
-
<h1>The Problem</h1>
201
-
<p>Panache is great for many things, but over time, we realised the following limitations:</p>
202
-
<ul>
203
-
<li>We have three distinct versions: Hibernate ORM, Hibernate Reactive and Mongo (blocking and reactive)</li>
204
-
<li>It is impossible to use the same entities with Hibernate ORM and Hibernate Reactive</li>
205
-
<li>Stateless sessions are not supported</li>
206
-
<li>Hibernate Processor annotations, and Jakarta Data are not supported</li>
207
-
<li>We have triplicate types such as <code>Sort</code> and <code>Order</code> between Panache, ORM and Jakarta Data</li>
208
-
<li>We have two ways to place entity query operations : on the entity itself, or in repositories</li>
209
-
<li>Entity query operations require type-system hacks which makes them less type-safe than we want with <code>var</code> and <code>for-each</code> and especially with reactive operations.</li>
210
-
</ul>
211
-
<h1>The proposed Solution</h1>
212
-
<p>We propose a new Panache version that will solve all these issues:</p>
213
-
<ul>
214
-
<li>Unify all variants in a single module, supporting blocking, reactive, stateless and stateful sessions</li>
215
-
<li>Provide an entity toplevel class for each 4 modes of operation, yet allow access to the other modes</li>
216
-
<li>Move all entity query operations from the entity class to the repository class</li>
217
-
<li>Provide a repository toplevel class for each 4 modes of operation, yet allow access to the other modes</li>
218
-
<li>Provide easy access to any type of repository by placing them as nested interfaces in the entity class, via a generated accessor on the entity metamodel class</li>
219
-
<li>Provide out of the box accessors for the 4 modes of operation repositories on the entity metamodel class</li>
220
-
<li>Support Jakarta Data and Hibernate Processor type-safe annotations</li>
221
-
<li>Optional: Support of Mongo via the coming ORM JDBC support</li>
222
-
<li>Optional: provide JD repository type alternatives for the missing three modes</li>
223
-
<li>Optional: provide a way to convert Panache 1 to Panache.Next</li>
224
-
</ul>
225
-
<h1>Definition of Done</h1>
226
-
<ul>
227
-
<li>Deliver the new Panache extension as a <code>stable</code> state (after preview/experimental versions for feedback)</li>
228
-
<li>Tests</li>
229
-
<li>Documentation</li>
230
-
<li>Codestart</li>
231
-
<li>REST Data with Panache support</li>
232
-
<li>Renarde support</li>
233
-
<li>Quarkus Insights</li>
234
-
</ul>
235
-
<h1>Scope of Work</h1>
236
-
<p>It is currently out of scope to retrofit this with the existing Panache modules. This will be a new module with no backward compatibility (although most type-unsafe operations will continue as-is, so you will be familiar with them).</p>
237
-
<h1>Organizing the Work</h1>
238
-
<h2>Communication and Transparency:</h2>
239
-
<p>This will be done via GitHub issues on the Quarkus core project.</p>
240
-
<h2>Expected Timeline:</h2>
241
-
<p>Most of the R&D and design work has been completed over the last two years. Now remains the task of merging, documenting, testing, and tweaking it until it's complete.</p>
242
-
<ul>
243
-
<li>Point of contact: @FroMage (@<strong>Stephane Epardaud</strong> on Zulip)</li>
Much of our work on Panache Next, soon to be renamed Quarkus Data, involved resolving several operation overload issues and refining Hibernate Reactive type signatures. We also enabled `StatelessSession` injection. Now, the team is tackling transaction propagation with Vert.x Context, allowing mixed `Session` and `StatelessSession`, and fixing projection failures with Kotlin value classes.
255
-
256
-
(This status update was automatically generated using AI.)
0 commit comments