Any interfaces. Wasn't even thinking about Cayenne-specific ones at that
point. Maybe I used the modeler more than you do. :-)
On Thu, Jul 14, 2022 at 4:15 PM Andrus Adamchik wrote:
>
>
> > On Jul 14, 2022, at 4:04 PM, Michael Gentry wrote:
> >
> > On Thu, Jul 14, 2022 at 3:47 PM Andrus Adamch
> On Jul 14, 2022, at 4:04 PM, Michael Gentry wrote:
>
> On Thu, Jul 14, 2022 at 3:47 PM Andrus Adamchik wrote:
>
>> I see. I suppose if we decide to go deep into class generation beyond
>> property handling, we will have other options, like generating interface
>> methods, etc.
>>
>
> For
On Thu, Jul 14, 2022 at 3:47 PM Andrus Adamchik wrote:
> I see. I suppose if we decide to go deep into class generation beyond
> property handling, we will have other options, like generating interface
> methods, etc.
>
For a modeler re-write, I was planning on having a section where you could
s
So even in your case you'd bootstrap ServerRuntime in a different way than that
legacy approach. And now there are two servlet options - javax and jakarta,
both requiring separate modules. So properly maintaining it in Cayenne is not
that trivial anymore. Maybe we move it to Cayenne examples ins
Java 17 "records" create some interesting possibilities as quick DTOs. Mapping
complex SQL is still rather painful in Cayenne. You'd get an Object[] as a
result and/or need complex scripting within SQL. I think records and some API
tweaks can help:
1. SQL result mapping.
record MyRecord(String
> I've rather hipothetical case in my head where one could use callbacks
> in the model to generate some project-specific code for the callback
> instead of just empty methods (like audit or validation logic).
> Maybe that's not an optimal solution for that (especially as we have
> listeners for in
I'm good with all of that. Except we do use cayenne-web (stateless). It's
not a lot of code so we could pull it in and keep our own copy, but I
wonder how many people are using it. We're not defining the serverRuntime
in web.xml (which would be a bit limiting and clunky), but otherwise I like
the c
I agree. Though I suggest to keep it in the current untested mode for another
cycle. Let's officially deprecate it in 5.0 and see if we get any feedback.
Andrus
> On Jul 7, 2022, at 2:46 PM, Nikita Timofeev wrote:
>
> Code itself is small and easy to maintain, as it doesn't do much. We
> just
