Longer term thoughts #3112
Replies: 10 comments 21 replies
-
|
Keep in mind that if you remove something you also make it more work to migrate to Ebean. Given that GraalVM native-image only compiles what is reachable + what it is being told to treat reachable, the size of the library doesn't have a huge impact. Personally it would be way better to give documentation a stronger focus. Without proper documentation, adoption is harder. Without knowing Ebean concepts on a technical level and without proper JavaDoc on internal classes contribution is also harder. |
Beta Was this translation helpful? Give feedback.
-
Yes, unused code removal is good there. The size of the lib will still impact compile time. Hard to say that the extra complexity for features like elementcollection and inheritance can be optimized out though - not sure.
Yes.
Yes. Feature removal is a serious call/issue. It impacts existing users. We'd do it for an important reason (like avoiding Rob burnout). |
Beta Was this translation helpful? Give feedback.
-
FYI: We do not use |
Beta Was this translation helpful? Give feedback.
-
|
Just to be clear, |
Beta Was this translation helpful? Give feedback.
-
|
We use Here at FOCONIS, Maybe we misused this annotation. The above should be possible with Maybe, the annotation can be renamed to |
Beta Was this translation helpful? Give feedback.
-
|
Ah ok, that is an interesting use. Good to know. A little bit like a
Yeah. Ultimately we don't want it confused with the ElasticSearch feature and that the name + documentation + tests makes it clear and obvious how it is expected to be used. [I don't recall tests for this, do we have tests for this?] |
Beta Was this translation helpful? Give feedback.
-
|
FYI: The full list of features that I'm thinking about for this experiment Going to keep
Changes in
|
Beta Was this translation helpful? Give feedback.
-
@rob-bygrave can you tell me why you don't want to support Sets in the future? |
Beta Was this translation helpful? Give feedback.
-
Removing support for Set is saying that there are NO known good use cases where we recommend its use - NONE. For Sets to be provide some value then the need some hashCode/equals implementation that effectively de-duplicates elements. The question becomes, is that ever a good idea. Is it ever a good idea to have rows in the database mapped into a Set and be implicitly de-duplicated in-memory on the application side always and automatically, as opposed to explicit de-duplication as and when needed. The only cases that I had hit have been better served by using Said differently, I know of NO known good use cases for Set but I know of several ways that people can mess it up. Just in the last week, we see #3173 and the question is, is that a good use of Set or actually a case where it should instead have been modelled as List and for the de-duplicate to be explicit? At this stage, I suspect when I see the failing test case for #3173 it will re-enforce the idea that Set is not good.
I'd be interested to see what this looks like in practice and why it's thought of as a good idea, why was Set was chosen, why was it chosen to de-dup via the model rather than explicitly etc. |
Beta Was this translation helpful? Give feedback.
-
|
I looked through some code and For |
Beta Was this translation helpful? Give feedback.
-
We often have code, that adds something, e.g with should be deduped. Mostly that are user objects, but here is a good example in a test case: class Role {
@ManyToMany
Set<Permission> permissions;
}If I want to add two permissions, I just call Set<Permission> tmp = new HashSet(role.getPermissions());
tmp.add(p1);
tmp.add(p2)
role.getPermissions().clear();
role.getPermissions().addAll(tmp);Of course, I can also implement it with List.contains, but I always must iterate through all elements of the list. The problem is, if adding It would be a good option, if we can implement some class Role {
@ManyToMany
List<Permission> _permissions;
@Transient
Set<Permission> permissions;
Set<Permission> getPermissions() {
if (permissions == null) {
permissions = new LinkedHashSet(_permissions); // or use a list, that invokes a callback on modification
}
return permissions;
}
void methodMustBeCalledBeforePersistEvenIfBeanIsNotDirty() {
if (permissions != null) {
_permissions.clear();
_permissions.addAll(permissions);
}
}
}This can be done for maps also, but ebean needs some mechanism to call a method, that writes back the state of the shadow field. |
Beta Was this translation helpful? Give feedback.
-
|
Well, I think I'm wanting to see more accurately HOW Set is being used and take stock of the tests that we have. What exactly does We could decide to keep support for Set if we are clear on how it can be used properly [perhaps we give Excellent guidance on hashCode/equals implementations]. |
Beta Was this translation helpful? Give feedback.
-
Never used this even in JPA.
No opinion, I never asked an ORM before to query something in a background thread. Usually the background thread has been created beforehand in the application.
Always good to hide internal stuff which is then of course free to remove.
Seems useful for certain people that have stronger security requirements (heath care, banking, ..). Maybe it is possible to add some hooks to ebean core so that this feature could be extracted as an ebean extension? Otherwise it has to be done in the DB itself but that might be more complicated as in the application.
Would make migrating to ebean more complicated as long as JPA supports both. It is quite some work to refactor large applications.
Maps are useful to speed up read access. Removing maps would make everyones code more ugly by introducing a transient map for reads (would also increase memory a bit, given two data structures for the same thing)
I sometimes use it for Enums with |
Beta Was this translation helpful? Give feedback.
-
|
What does a |
Beta Was this translation helpful? Give feedback.
-
|
My bad. I mixed something up. I did a quick search again and there are like 10 |
Beta Was this translation helpful? Give feedback.
-
Hmm, bit of a blow that. ElementCollection might not be easy to deal with without built in support in the ORM itself. Hmm. |
Beta Was this translation helpful? Give feedback.
-
FYI: 17 odd years ago this started as the idea that ebean could "Build object graphs in parallel" and this is effectively the remnants of that original idea. Today |
Beta Was this translation helpful? Give feedback.
-
|
As a side note: With Java 21 virtual threads it is probably also a good idea to look for synchronized blocks / object.wait() within ebean to avoid thread pinning. But I think many JDBC drivers will have trouble with this as well. |
Beta Was this translation helpful? Give feedback.
-
Already done. I did that ages ago and so there is no use of synchronised in ebean.
I'm also the guy that got the change into PostgreSQL JDBC Driver to remove the synchronised there (which is the JDBC driver I care most about). So yeah, I'm good to go with Virtual Threads. Just waiting on Helidon Nima now. |
Beta Was this translation helpful? Give feedback.
-
Sounds nice but wondering how jetty with virtual threads compare against it on pure HTTP performance. |
Beta Was this translation helpful? Give feedback.
-
Indeed. The implementation of Nima is really simple and uses VT per connection. Jetty 12 core now looks like its "async only" and to me that implies that with Jetty 12 there is always going to be the handoff from worker threads to Virtual Threads (unlike Jetty 11). The Nima HTTP 1.0 & 1.1 implementation to me looks really nice and simple. The Helidon team have been benchmarking against Netty (Helidon 3.x is Netty based) and they are "All In" on Nima and Virtual Threads. |
Beta Was this translation helpful? Give feedback.
-
Oh, just to say this was the way I did all my original Loom / Virtual Threads performance testing. Ran Jetty using platform threads vs loom with various "simulations of IO wait" using LockSupport. That and using JDK HttpClient with Virtual Threads. This is how I got very comfortable with the performance of Loom. I have not update those tests and re-ran them for ages. I believe Jetty 12 makes that harder so if I re-run those tests I'll probably stick to Jetty 11. Those tests could also now run with actual IO wait like actual JDBC calls to a DB rather than simulation via LockSupport. |
Beta Was this translation helpful? Give feedback.
-
|
For the other points:
I never used it as I haven't used Ebean extensively so far but I generally liked the idea.
Would it be possibly to define extension points within Ebean so that such mechanisms can be implemented outside of ebean as an extension / plugin? Or is it maybe already possible but very complex to discover in the current API?
I don't use it but this would be pure hell for migration from JPA.
I use it quite a bit with
No real opinion except that I always prefer to not reference DB table/columns in strings other than the ones in entities.
No real opinion other than full text search is usually important. But of course if could be implemented externally as long as you can detect that data has been changed.
I tried once to serialize ebean entities to json using GSON but that failed miserably because it uses reflection. So I discovered Ebean JSON serialization but somehow I wasn't really able to configure it properly. Documentation should somewhere state that a JSON serializer must call methods and not use field based reflection. At the end I created DTOs + mappers with exactly what I needed and used GSON to serialize the DTOs. I would have loved to just be able to add some "ignore this field and that field" configuration and then serialize the entity. |
Beta Was this translation helpful? Give feedback.
-
You'd use |
Beta Was this translation helpful? Give feedback.
-
Inheritance looks innocent enough but it has runtime costs and complexity costs. Ask the question, would you ever use inheritance if you were using SQL and JDBC? Going back to conceptual Logical Modelling and Physical Modelling then yes inheritance comes from that area and is pretty well defined BUT in 2023 no RDBMS that we care about has the concept and so using ORM It will interesting to see how I feel with a diff that removes it wrt how much complexity that removes from the code base. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm. We are using @Inheritance with the @docstore annotation when storing jsons. We do not use it anymore when storing db-beans. I'll try to provide a testcase/showcase tomorrw, what we do exactly and what we really need. Then we can discuss, if there is a way to model that in ebean or we have to switch to alternatives (e. g. Jackson subtypes) . |
Beta Was this translation helpful? Give feedback.
-
|
Please don't remove "@ElementCollection" as we are currently also using it for our Enum (similar to jnehlmeier's comment above ) |
Beta Was this translation helpful? Give feedback.
-
|
To be clear, there is a ebean-15x branch that has all those other changes already made and that branch has been sitting there ready to go pretty much for a few weeks now. I've been keeping that branch up to date (rebasing). There will be |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much for the clarification and the work you've put into the ebean! |
Beta Was this translation helpful? Give feedback.
-
|
Sad for us to hear that @Inheritance is being removed. We have used it successfully many times |
Beta Was this translation helpful? Give feedback.
-
|
Ok. You can try and make the case for it? You should probably look to address the issues around runtime performance (like reference beans require a query) etc and perhaps. Ultimately its a cost/benefit call right and that has to also take into account the internal complexity than gets removed when the feature is removed (not sure if you've looked at the commits that removed the features). |
Beta Was this translation helpful? Give feedback.
-
Ebean is getting close to 17 years old now and a few things have me thinking about what the next 10 odd years might look like.
In case you missed it Oracle announced that the Graal Enterprise features are going to be free. To me this is another pointer that the future is about smaller, simpler, faster, lighter and probably "more native compilation"- that native-image is going to come to larger adoption sooner than I previously thought.
I'm conscience that ebea-core is a ~2Mb jar (and I also see another major ORM has it's core jar coming in at ~ 11Mb). The JPA spec was pretty much completely dormant for a long long time now but now has popped back to life. To some extent that is good but it perhaps is a reminder that Ebean naturally took on JPA Mapping support when some of it was in my opinion poor and some of it now looks dated. I'm especially aware that I personally really don't like
@ElementCollectionand I don't like@Inheritanceand I have never chosen to use either - ever !!!.I'm also aware that at this point we are very unlikely to see more assistance in the form of contributing to docs, examples, code or sponsors that fund more time for docs, examples, code etc. We need to be aware of what Ebean can take on in terms of features and complexity.
With these background thoughts I have in mind to do a little bit of research in terms of how much simplicity we can get from removing some features like for example Named queries (no more antlr4 dependency etc).
Cheers, Rob.
Beta Was this translation helpful? Give feedback.
All reactions