Longer term thoughts #3112
Replies: 10 comments 26 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.
-
|
We're stumbling onto (single table) inheritance being removed as well. Although I understand that inheritance often is overused, polymorphism is a core part of object oriented programming, and removing this will have a great impact on allowed architectures. There is nothing wrong with inheritance, if used correctly. |
Beta Was this translation helpful? Give feedback.
-
|
We've also been happily using Inheritance in some of our entities for many years in a fairly large JEE application (+- million loc) and will be impacted a lot by this removal. Looking at the diff and the many properties, if statements and tests that were removed I understand the want to reduce complexity in Ebean. Inheritance is also not my preferred strategy to apply to most cases but it's part of the language and the JPA spec. Removing this will make it harder for other developers to make the move from Hibernate (or other JPA implementations) to Ebean. I much prefer Ebean to Hibernate due to better query builders, explicit saves and the way it deals with loading relations. Still, I'm finding it harder to justify to my team to stay on Ebean. |
Beta Was this translation helpful? Give feedback.
-
|
So firstly, we do have some time to gather feedback and comments on We are keeping these releases in parallel because generally speaking people are not reading release notes etc and so there is some expectation of some delay in terms of folks finally getting to update apps and only then coming to here at that point to give feedback - and that's ok but to some extent we can't wait forever for everyone to participate. The first 15.x release was Feb so that's already 7 months ago. There is some possibility that inheritance makes it back into 15.x and we will probably know in Feb how it's going when 15.x would then have been out there for 1 year. We will have more comments added here, more participation, more feedback etc.
When we have a relationship To an entity bean with inheritance, we can no longer instantiate a reference bean for that without the discriminator. That is, the foreign key value by itself is no longer sufficient to create a reference bean and instead we additionally require the discriminator value and in order to get that ebean will add an extra sql join to that table [that has the inheritance] to obtain the discriminator value. We have this same scenario with So this is the first extra cost we get when we use Another thing we hit with single table inheritance is how we real with NOT NULL constraints on properties that are not on the base type. IMO there isn't really an optimal solution there. Internally within ebean we get complexity when we have an inheritance hierarchy with different relationships [ManyToOne, OneToMany etc] on different parts of the inheritance hierarchy. [We have "different shapes" with "different paths"]. Alternatives to
|
Beta Was this translation helpful? Give feedback.
-
|
I do not understand why single table inheritance would require an additional join. "Single table" says it already: there is only one table, what extra join can there be? All it should take is an in-memory map of discriminator values to actual class, and upon instantiation a lookup in that table which class to instantiate. I can see that partial selects are not an option anymore, because you first need to get the discriminator to decide what fields should be fetched, and with that select you might as well get the other fields as well. But that IMHO is a trade off for the developer to make. And yes, using @inherited often has drawbacks; in the most optimal setup all the data is in a base class, and the extending classes only have differences on code level. Suppose Vehicle has a method calculateMaxCargo(), which differs only in code between Car and Truck. This is a natural fit for OO languages, where the use of inheritance is perfectly fine, and has no issues with any database constraints. Being forced to use interfaces and implementations is not a natural fit. But even if there are database complexities, like columns that are NOT NULL but not mapped in all extending classes, it is not the job of the ORM to deal with that. It is a design consideration of the developer; either use Inherited and somehow deal with that NOT NULL, or use another pattern. Nicely undermining the point I'm trying to make: one could argue that if you want inheritance in the domain model, trying to shoe-horn persistency onto the same model is not a good idea. JPA annotations are a way to re-use the domain model classes for persistency, which may not be at all suited for that. If the domain model classes cannot be easily used, a repository layer with DTO alike classes specifically for persistency (still using the annotations of course) may be needed. Maybe only for the one entity. When persisting a domain class, it first needs to be converted to repository layer classes, and vice versa. Not optimal, but IMHO better than not using natural OO architectures - if they are a good fit for a situation. But the point remains: there is always a price to pay, in code complexity, in less optimal database constraints, everything is a trade-off. But it should be up to the developer to decide where that price is due; not supporting inheritance in an OO language is IMHO a bad idea. |
Beta Was this translation helpful? Give feedback.
-
Any table with a foreign key column to a table with inheritance. e.g. Trip has a ManyToOne to Vehicle ... and Vehicle uses inheritance with Car and Truck subtypes. The trip table as a fk column When we query trips, the orm reads the vehicle_id column, but that is not sufficient to create a reference bean for vehicle because it is using inheritance and it needs to create the reference bean with the correct type. It needs the discriminator value, and that is over in the vehicle table. So when we query trip it adds a join to vehicle such that it can read the value from the vehicle_id column AND the discriminator value. This is the case that means we get an extra join required purely due to |
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