Longer term thoughts #3112
Replies: 11 comments 28 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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Sad for us to hear that @Inheritance is being removed. We have used it successfully many times |
Beta Was this translation helpful? Give feedback.
-
We are considering switching from JPA to Ebean because of the following features:
I'm not sure if we will stick with Ebean if |
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
@ElementCollection
and I don't like@Inheritance
and 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