Re: OpenJPA support for JPA 2.1: when?
I'm not concerned about the fact that most OpenJPA committers are IBM employees, but committership *is* de facto closed by the usual Apache meritocracy principles. If you don't get enough volunteers among Apache members for upgrading OpenJPA to JPA 2.1, you might start thinking about making it easier for people to contribute and/or become Apache members. In the age of DVCS, contributing a feature to an open source project should not be harder than creating an issue, forking a repository, writing some code and submitting a pull request. IMHO, Apache is more of a cathedral than a bazaar - for potential contributors willing to code in their spare time, the entry barrier is too high. Best regards, Harald
OneToMany Delete Order Problem
I have a unidirectional one to many relationship defined but I am getting a foreign key constraint violation when attempting to run a delete on the entity. It appears the delete statements are not being issued in the correct order. The entity record is being deleted before the records with the foreign key references. Is there any way to get them ordered properly? Configuration details follow.. OpenJPA 2.2.1-SNAPSHOT (Websphere Version) Annotations on entity field @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, orphanRemoval = true) @JoinColumn(name = ID_XXX, referencedColumnName = ID_XXX, nullable = false) -- View this message in context: http://openjpa.208410.n2.nabble.com/OneToMany-Delete-Order-Problem-tp7584211.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: OpenJPA support for JPA 2.1: when?
Hi, Matthew asks a pertinent question: When will OpenJPA support JPA 2.1? Kevin's response is factual as well Pinaki has went so far to create a sandbox and start experimenting with an implementation. Again, he's a one-man show and can't do it all. Well, he probably could, but it would require a bit of work... :-) I have done some analysis of the required changes to trunk to comply with JPA 2.1. And made some preliminary implementation work. But, as Kevin observes, Open Source is *not* a one-man show. It thrives on voluntary participation, where *anyone* can contribute if they are passionate about what they do. Not because they belong to a club of one sort or other. So for anyone reading this mail, you are welcome to express your wish to participate in OpenJPA community. You need not to be a member of any particular group or country, your only credential is you. You can write to me in confidence and I will organize the due process to welcome you in the fold. Someone in this thread had raised a doubt about current active participation being dominated by the employees of a single company. But I can assure you based on my association with many of them, that they are excellent engineers who had earned the karma by their own merit and open-minded enough to welcome you irrespective of who pays your bill or which country you live. - About complying to a 2.1 JPA spec version, we should honor a pair of key principles that OpenJPA (or its predecessor Kodo) had always followed: a) it is not driven by a de jure specification and aspires to stay ahead of the curve via innovative features (that perhaps no customer is asking for at that point of times) b) its kernel is agnostic to datastore being of a particular kind (NoSQL enthusiasts should take note ;) While I will keep aside the later design principle for now, the former principle applies for the current topic. This forward-looking tendency can be observed when many new JPA features can be mapped onto existing OpenJPA features (FetchPlan being a notable example). So it does sound strange when we discuss about implementing JPA 2.1 features as if the decision is subjected to someone asking for it. A Open Source group builds features not because a spec committee or a customer, but because , the members, as engineers, think that a feature will be useful -- today or tomorrow. Time may prove otherwise, but unless we carry that spirit of innovation backed by our love for a technology domain, we, as a group, will fall into the trap of factory-built, proprietary software that is so twentieth century. Yes, a popular spec like JPA can provide a guideline, but our decision of how to take OpenJPA forward should not depend on it. - Pinaki Poddar Chair, Apache OpenJPA Project -- View this message in context: http://openjpa.208410.n2.nabble.com/OpenJPA-support-for-JPA-2-1-when-tp7584157p7584212.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: OpenJPA support for JPA 2.1: when?
On Tue, Jun 18, 2013 at 12:34 PM, Pinaki Poddar ppod...@apache.org wrote: While I will keep aside the later design principle for now, the former principle applies for the current topic. This forward-looking tendency can be observed when many new JPA features can be mapped onto existing OpenJPA features (FetchPlan being a notable example). So it does sound strange when we discuss about implementing JPA 2.1 features as if the decision is subjected to someone asking for it. A Open Source group builds features not because a spec committee or a customer, but because , the members, as engineers, think that a feature will be useful -- today or tomorrow. Time may prove otherwise, but unless we carry that spirit of innovation backed by our love for a technology domain, we, as a group, will fall into the trap of factory-built, proprietary software that is so twentieth century. Yes, a popular spec like JPA can provide a guideline, but our decision of how to take OpenJPA forward should not depend on it. I agree with you to a certain point, Pinaki. Yes, with open source, folks are free to innovate and see what's valuable, but in the face of limited resources, it does make sense that resources be assigned in order to address those issues with the most votes. The thorn in the side of this desire-ocracy is the need to implement the specification that, like it or not, defines the minimum bar of entry of the space OpenJPA occupies. For OpenJPA to remain competitive, it not only has to implement those features that have been commoditized by the specification, but also innovate to provide value above and beyond the specification. I am pretty comfortable saying that most customers are going to expect matter-of-factly that OpenJPA implement the latest version of JPA, with an appropriate, but small, lag time after the specification's GA release, which was in May 2013. Otherwise, OpenJPA is at a disadvantage in a competitive situation versus other persistence implementations. Further, it is usually those innovative features that tip an organization's decision to use X or Y. The various JPA implementations find themselves in the now-common dilemma of having their features commoditized by the spec, which then puts pressure on them to innovate. After a particular innovation (or set thereof) is commonplace across implementations, it is standardized and commoditized, and the cycle repeats. I see this a Good Thing. Personally, I think all of the implementations should be striving to implement JDO, since it is and always has been datastore-agnostic and there is a significant NoSQL movement. Most of JPA's innovations have been longstanding features of JDO for years, including fetch plans/entity graphs. Contrary to what many think, JDO has continued undergoing active development this whole time, and 3.1 is now beginning its release process. I have long told customers that if their priority is have choice of implementation, then go with JPA, but if their priority is choice of datastore type, then go with JDO. Hibernate, EclipseLink and Batoo may be conventionally thought of as OpenJPA's competition, but forward thinkers should see DataNucleus as the primary competition, especially as people continue to consider NoSQL solutions. In any case, OpenJPA must, IMHO, implement JPA 2.1 ASAP to be considered legitimate in the space. Further, the roadmap should be to target JDO compliance, as Pinaki alluded to in describing OpenJPA's datastore-agnostic kernel (thanks to its predecessor, Kodo). I mean, seriously, the writing is on the wall. I guess I'm up to my $0.04 now... :) -matthew
