Menu
▾
▴
aplaws-devel
|
From: Aplaws D. L. <apl...@li...> - 2009-06-15 10:07:09
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7444884 By: lbcfrancois Hi all, As you know we have an outstanding issue with PostgreSQL 8.3.x. We are currently looking at all the available options and one of them would be to use Hibernate (https://www.hibernate.org/). Has anybody already looked into it and would have some paper (even in rough draft format) of the different item of work that would be required? Please don't hesitate to send us your feedback on the idea as should we go down this route 1.0.5 would be shipped most likely with no support for PostgreSQL beyond 8.2. Cheers, Francois ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-15 13:26:18
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7445185 By: shawnlane >As you know we have an outstanding issue with PostgreSQL 8.3.x What issue do you have? If it is performance, then we had a performance issue but this was solved by changing a parameter on the JDBC URL to speak the correct protocol. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-15 13:34:56
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7445198 By: shawnlane NB just checked our database and it's 8.1.1... can you let me know what the problem is with the later version. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-15 13:40:10
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7445208 By: lbcfrancois The issue is that it won't install. This was put together by Peter Boy - Thanks Peter for documenting this. A description of the issue is located at https://fedorahosted.org/aplaws/ticket/29. The issue can be reproduced as follows: - Install Postgresql 8.3 - Compile and Deploy current branch 1.0.5 - As soon as you execute ccm load-bundle you will receive the first error message concerning incompatible fields (revision 1760 has not been included in the branch 1.0.5 , so as to provide an unmodified system to fix the postgresql issue.) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-15 13:59:12
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7445251 By: shawnlane This might help http://archives.postgresql.org/pgsql-patches/2008-05/msg00397.php ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-15 14:15:53
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7445285 By: lbcfrancois that's useful. However I do not know whether this patch would be supported within an enterprise level support agreement. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-17 07:49:03
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7448948 By: pboy Hi, I suppose the patch will not resolve the problem in hand. as to the current problem evaluation Postgresql version 8.3 and beyond has stopped to auto convert string variables into the appropriate data type of a field. APLAWS persistence relies on that feature. If we decide to switch to Hibernate we would have to do a lot of code modifications which will break the API. The main goal of release 1.0.5 is to preserve the current API and runtime system. So Hibernate is not an option, indeed. Jens, member of our development team at Bremen, will present a paper which analyses the work we have to do in order to switch to Hibernate. It is a lot of work, so we have to decide wether we will migrate to Hibernate (and preserve the current object mapping) or switch to Java Content Repository (modify a lot of the internal logic). Therefore, the Postgresql problem should be resolved in Red Hat persistence. For a developer familiar with the code it shouldn't be an overwhelming task. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-17 10:02:34
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7449221 By: lbcfrancois I agree with you Peter on that Hibernate will not be part of 1.0.5 as it will break API Peter, do you know when Jens paper will be ready? We are currently also looking at getting an estimate together for the work involved in switching to Hibernate. I know we were talking about moving to JCR, but during our investigation to fix the 8.3 PostgreSQL bug, hibernate cropped up in the discussion and I think is worth investigating. It would be good to have people opinion around Hibernate vs. JCR (i.e Jackrabbit) so we can see which one would benefit Aplaws the most going forward. Francois ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-17 11:12:21
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7449316 By: pboy Francois, I suppose, Jens will upload the paper today. I just accepted him as developer on sourceforge so he can access the forum. Jens estimates, a developer needs 3 - 6 months for the move. The most complex and time consuming task is to clean up the code and rework the the class hierarchy. There is a lot of unfinished work in core, e.g. old vs. new versioning, site node, search framework, and more. Old design patterns and implementations coexist with previous ones and make the class hierarchy (and object relational mapping) inconsistent and ambiguous. The time a developer needs for a rework depends largely upon his familiarity with the code in core (and partly cms). I agree, a migration to Hibernate is a valid alternative to a migration to JCR. It is by far less work, we retain flexibility, and don't have to undertake the huge task to reconstruct the internal logic of rather the complete code in core. And - as a rough estimatation - more of half of the work (perhaps2/3) we have to do anyway, independently wether we migrate to Hibernate or to JCR. So, it may be a wise decision, to migrate to Hibernate in a first step. We achive a wider database support, easier code maintenance, and fix several database problems. We can invest the saved workload into a greater user friendlyness and other user related improvements. A year later we may investigate a switch to JCR. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-17 19:31:46
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7449477 By: shawnlane You might need to think who your doing this for. Hibernate will ease development and make it more attractive to developers and easier to port to other databases. I think if your thinking about organisations however, hibernate is irrelevant, organisations are more likely to be diven by standards and will therefore be looking for a product that supports the JCR standard and the upcoming CMIS (Content Management Interoperability Services). In other words the implementation of persistence is irrelevant. In other words larger organisations witll be looking for products / open source options that meet these standards. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-18 00:32:21
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7450550 By: terry_permeance If someone has a passion for converting aplaws to use Hibernate then by all means go for it. Personally, I think PDL does the job quite well. I think implementing standards such as JSR170 and JSR286 and so on are more important. Also, have a look at Mirage (https://mirage.dev.java.net/). It's kind of like the "apache commons" for CMS. Regards, Terry ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-18 08:07:53
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7451077 By: pboy | organisations are more likely to be diven by standards and will therefore be | looking for a product that supports the JCR standard and the upcoming | CMIS (Content Management Interoperability Services). Given the current market situation I'm not shure about that. :-) Nevertheless, Hibernate is one implementation of a standard (Java Persistence API). Organisations and users might look for features (e.g. support for different databases), usability, performance, etc. Hibernate (probably as an intermediate step) will open a chance for improvements in a foreseeable time frame. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-17 14:50:46
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7449655 By: jensp1108 Hello to all, the paper describing the necessary modifications for using the JPA in CCM/Aplaws is now available: http://ccm.barkhof.uni-bremen.de/ccm/cms-service/stream/asset/?asset_id=74010 In the paper I assume that we want to use the standardised Java Persistence API and not Hibernate directly. I agree with Shawn that our final goal should be to migrate to the JCR. Besides the JCR there are also other parts of CCM which need some work. I'm working on a paper which describes the existing options that we have. I hope to finish this paper by the end of June. As Peter stated above, for migrating to JCR will cause some extensive modifications in the code and needs a big amount a conceptional work. The JCR is not an relational database, it has a model which shares some characteristics with hierarchical databases. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-17 16:58:56
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7449918 By: lbcfrancois I guess the question would then be, would it mkae the roadmap easier to move from RedHat persistence to Hibernate and then from Hibernate to JCR and maybe CMIS when it gets finalised. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-18 08:00:19
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7451067 By: pboy Francois, | would it mkae the roadmap easier to move from RedHat persistence to Hibernate | and then from Hibernate to JCR personally I have a slight preference to that route. If we move directly to JCR we have not only to rework and clean up the class hierarchy, the deprecated parts of the code, and all the unfinished work spreaded over several packages, but also to *redesign* large parts of the code as we move from an object relational persistence to a sort of hierarchical persistence. To perform all of that work in one step has - mathematically spoken - a lot of "degrees of freedom", may be to much, and carries the risk to evolve into an unmanageable, insolvable, never ending process. Hibernate is an implementation of the Java Persistence API, which inherited the basic design from the JDO framework which in turn has very similiar design principles as CCM persistence (which may be seen as a first draft of JDO). The migration process is better foreseeable and will result rather soon in a working, improved, and easier maintainable code base. A large part of the work is a quite mechanically refactoring, some sort of boring but very likely to be performed in a short time frame. From that level it is easier and better managable to migrate to JCR if we decide to do so. And: Currently nobody made a detailed analysis, whether JCR meets all the requirements of APLAWS's feature set or what changes are necessary. Given the current code state it is very difficult, perhaps impossible, to make such an analysis. Just my thoughts. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-23 19:27:48
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7460154 By: bprucha Just to throw my $.02 in, I agree with others about adopting Hibernate or another implementation of Java Persistence API. It is a standard just like JCR so I don't get the argument that companies will want JCR over it. It fits in well with the exising architecture. I have looked into the Alfresco code and it's use of JCR and I considered the design very messy and not scalable. The developers of Alfresco had to rely on Lucene indexs to provide efficient data lookup. Having to sync the Lucene index with the JCR data was a real burden and caused unexpected results when they weren't synced properly. Relational databases still rule and JCR has not proven itself IMHO. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-24 06:26:25
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7460837 By: jensp1108 Maybe there is an option which allows us to support the JPA and JCR. The JPA is designed for persisting Java Beans is an relational database. This task is called Object Relational Mapping (ORM). The JPA uses annotations or XML files to mark the properties which should be stored into the database. The Apache Jackrabbit provides something very similar for the JCR. They call it Object Content Mapping (OCM): http://jackrabbit.apache.org/object-content-mapping.html. OCM works very similar to the JPA. The objects to store must be Java Beans, and you mark the properties to store with annotations or in a XML file. So if we use XML files for the JPA instead of annotations we can switch very easily to JCR. The methods needed for reading and writing are very similar, so that it should be easy to design an interface containing these methods. This interface would be implemented by a class which maps the methods from the interface to the concrete methods of the JPA or the Jackrabbit OCM implementation. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-24 15:26:17
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7461752 By: bprucha Just to throw my $.02 in, I agree with others about adopting Hibernate or another implementation of Java Persistence API. It is a standard just like JCR so I don't get the argument that companies will want JCR over it. It fits in well with the exising architecture. I have looked into the Alfresco code and it's use of JCR and I considered the design very messy and not scalable. The developers of Alfresco had to rely on Lucene indexs to provide efficient data lookup. Having to sync the Lucene index with the JCR data was a real burden and caused unexpected results when they weren't synced properly. Relational databases still rule and JCR has not proven itself IMHO. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
|
From: Aplaws D. L. <apl...@li...> - 2009-06-27 19:31:48
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7467376 By: pboy Hi Brett, thank you very much for the work to inspect the Alfresco code. I think, a dependency from lucene indexes for efficient data lookups is an obsolute "KO criterion". We are all glad that the performance problems of the early APLAWS / CCM version could be resolved by extensive caching and tuning persistence. So, we should take the hibernate route. According to Jens' proposal we may construct an interface which allows to connect to hibernate or to JCR,when JCR becomes mature. CCM follows an highly sophisticated object oriented design which we should not dispense. Peter ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=368401 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X