Re: [Dspace-tech] [Dspace-devel] PLEASE VOTE on whether to include Services API refactoring in DSpace 6.0
On Thu, Aug 06, 2015 at 11:06:52PM +0200, Adan Román Ruiz wrote: Its a good idea, but there are alternatives to hibernate. Why not mybatis? We keep saying Hibernate, but we should be thinking JPA. If MyBatis implements JPA then you should be able to swap it in. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: Digital signature -- ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] [Dspace-devel] PLEASE VOTE on whether to include Services API refactoring in DSpace 6.0
Its a good idea, but there are alternatives to hibernate. Why not mybatis? +1 the proposal makes good sense and I will be happy not doing straight SQL any more +1 — Monika Mevenkamp Digital Repository Infrastructure Developer Phone: 609-258-4161 333C 701 Carnegie, Princeton University, Princeton, NJ 08544 On Aug 6, 2015, at 12:45 PM, Peter Dietz pe...@longsight.com mailto:pe...@longsight.com wrote: I am happy to have an ORM added. I'm not really a fan of adding ClassDAO, ClassService, ClassServiceImpl for each class, it feels verbose, but I guess it separates concerns. My coworkers' experience with Hibernate is that it does 90% of things well, but the remaining 10% is a major pain. Code where you thought you were making 1 query turns into thousands of queries. I'd like to see some performance comparisons between our native SQL, and hibernate's execution plan. Hibernate's caching and lazy-loading sound like improvements though. I'm supportive, I'll dig in, to see if I find any deal breakers. Peter Dietz Longsight www.longsight.com http://www.longsight.com/ pe...@longsight.com mailto:pe...@longsight.com p: 740-599-5005 x809 On Thu, Aug 6, 2015 at 11:20 AM, Bram Luyten b...@atmire.com mailto:b...@atmire.com wrote: +1 Bram -- logo *Bram Luyten* /250 Lucius Gordon Drive, Suite B-3A, West Henrietta, NY 14586/ /Esperantolaan 4, Heverlee 3001, Belgium/ www.atmire.com http://atmire.com/website/?q=servicesutm_source=emailfooterutm_medium=emailutm_campaign=braml On 6 August 2015 at 16:50, Tim Donohue tdono...@duraspace.org mailto:tdono...@duraspace.org wrote: I vote +1 - Tim On 8/6/2015 9:47 AM, Tim Donohue wrote: Hi Developers / Committers, As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release. As this change constitutes a major code refactor of the dspace-api (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0. (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email) Please VOTE with one of these three options: +1 = I agree. We should include Services API refactoring in 6.0 0 = I'm undecided / unsure (Please provide a reason) -1 = I disagree. The Services API refactoring should NOT be included in 6.0 (Please provide a reason why you disagree) Per our Voting Procedures [1], a vote on code modifications requires: at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'. While /anyone/ is welcome to vote, only Committers have binding votes (and can cast a veto). Others are free to vote to express your opinion, but those votes are considered advisory in nature. This public vote will be open until *15:00 UTC (11:00am EDT) on Wednesday, August 12* (which is the time of our next Developer Meeting). If there are any questions, feel free to ask them on this thread. *Summary of Services API refactoring* The Services API refactoring is a major refactoring of the dspace-api (DSpace's Java API) to better support separation of concerns/responsibilities. Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace Services API attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.org http://hibernate.org/). The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate). Much more information with documentation, tutorials/examples, and a video presentation at: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api What does adding this refactor to 6.0 mean? * This is essentially a *new* Java API for DSpace. But, it performs a very important refactor (see Pros below). * It is not backwards compatible with the existing API. All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using
Re: [Dspace-tech] [Dspace-devel] PLEASE VOTE on whether to include Services API refactoring in DSpace 6.0
the proposal makes good sense and I will be happy not doing straight SQL any more +1 — Monika Mevenkamp Digital Repository Infrastructure Developer Phone: 609-258-4161 333C 701 Carnegie, Princeton University, Princeton, NJ 08544 On Aug 6, 2015, at 12:45 PM, Peter Dietz pe...@longsight.commailto:pe...@longsight.com wrote: I am happy to have an ORM added. I'm not really a fan of adding ClassDAO, ClassService, ClassServiceImpl for each class, it feels verbose, but I guess it separates concerns. My coworkers' experience with Hibernate is that it does 90% of things well, but the remaining 10% is a major pain. Code where you thought you were making 1 query turns into thousands of queries. I'd like to see some performance comparisons between our native SQL, and hibernate's execution plan. Hibernate's caching and lazy-loading sound like improvements though. I'm supportive, I'll dig in, to see if I find any deal breakers. Peter Dietz Longsight www.longsight.comhttp://www.longsight.com/ pe...@longsight.commailto:pe...@longsight.com p: 740-599-5005 x809 On Thu, Aug 6, 2015 at 11:20 AM, Bram Luyten b...@atmire.commailto:b...@atmire.com wrote: +1 Bram -- [logo] Bram Luyten 250 Lucius Gordon Drive, Suite B-3A, West Henrietta, NY 14586 Esperantolaan 4, Heverlee 3001, Belgium www.atmire.comhttp://atmire.com/website/?q=servicesutm_source=emailfooterutm_medium=emailutm_campaign=braml On 6 August 2015 at 16:50, Tim Donohue tdono...@duraspace.orgmailto:tdono...@duraspace.org wrote: I vote +1 - Tim On 8/6/2015 9:47 AM, Tim Donohue wrote: Hi Developers / Committers, As mentioned in yesterday's developers meeting, I'm calling a public VOTE around whether we include the Services API refactoring in the upcoming DSpace 6.0 release. As this change constitutes a major code refactor of the dspace-api (DSpace Java API), we'd appreciate feedback from anyone on this direction for 6.0. (If you have not yet read about the Services API refactoring, a brief summary and links to more information is provided at the end of this email) Please VOTE with one of these three options: +1 = I agree. We should include Services API refactoring in 6.0 0 = I'm undecided / unsure (Please provide a reason) -1 = I disagree. The Services API refactoring should NOT be included in 6.0 (Please provide a reason why you disagree) Per our Voting Procedures [1], a vote on code modifications requires: at least three positive (+1) votes, and no negative votes (-1) to pass. In this scenario, a negative vote constitutes a 'veto'. While anyone is welcome to vote, only Committers have binding votes (and can cast a veto). Others are free to vote to express your opinion, but those votes are considered advisory in nature. This public vote will be open until 15:00 UTC (11:00am EDT) on Wednesday, August 12 (which is the time of our next Developer Meeting). If there are any questions, feel free to ask them on this thread. Summary of Services API refactoring The Services API refactoring is a major refactoring of the dspace-api (DSpace's Java API) to better support separation of concerns/responsibilities. Simply put, often, in the existing API, there is an intermingling of business logic and database logic which is difficult to maintain, debug and/or build against. One of the most obvious examples is how we deal with database software support (PostgreSQL vs. Oracle), but such intermingling of logic exists in many of our core classes. The DSpace Services API attempts to tease apart the database logic from the business logic into separate layers, while also adding support for Hibernate (http://hibernate.orghttp://hibernate.org/). The goal is to provide an easier to maintain, more modular API, while also enhancing how we deal with database logic in general (via Hibernate). Much more information with documentation, tutorials/examples, and a video presentation at: https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api What does adding this refactor to 6.0 mean? * This is essentially a *new* Java API for DSpace. But, it performs a very important refactor (see Pros below). * It is not backwards compatible with the existing API. All developers and Committers who work with the Java API will need to learn this new API, as all future development will require using this Java API. * Committers will be expected to learn, use and support this API immediately. @mire will be providing additional training materials / examples to help everyone get up to speed. * We also will need immediate help from Committers (or other volunteers) to refactor and test all other modules within DSpace. Currently, only the XMLUI has been refactored to support this new API. All other modules (JSPUI, OAI, REST, RDF, SWORD, etc) will need similar refactoring as soon as possible. * If this refactor is voted in, Committers will immediately do the following: * The master
