Sorry for the late response, still busy on my other projects (currently in release cycle)
please see inline 2012/4/12 [email protected] <[email protected]> > > 1.e) *All data beans need to be unified to have "automatic references" to > related objects like * > *MeetingMember.meetingMemberId should be reference to internal object not > just Long.* > => I don't understand this point. We are using primitive type "long" for > primary keys. What is wrong with that reference? > I think instead of having meetingMemberId as long we should have meetingMember as User (or Member or any other bean name). for example in Users.java we have: @JoinColumn(name = "adresses_id", insertable = true, updatable = true) private Adresses adresses; NOT private Long adresses_id; I also think it is good idea to rename Users to User, Adresses to Address etc. > 1.f) > => I totally agree that Management Classes VS Dao(-Impl) is currently > inconsistent. > However from my point of view you can't put all logic in the Dao(-Impl) > classes. > Dao's basically access the DB and fill the Beans. Nothing else. There will > be still some Management-Classes that contain methods that access multiple > Dao's, for example the registration. You would not put the whole > registration logic in a single Dao nor would you put all the logic in the > Service classes. > The design could be with 3 Layers: > 1) Service-Classes (Axis2 or Red5): Entry Point, validates input > 2) ManagementClasses (Maybe Rename with different Naming Pattern, for > example UserHandler instead of UserManagement like the "MailHandler") > 3) DaoImpl (access to DB) > [It would be still allowed from my point of view to put minor business > logic into the Service Class and bypassing the Management Class of layer 2) > and go directly from 1) to 3) ] > I agree I would strongly recommend to leave all DB relative actions in the DAOImpl with using NamedQueries > > So the task would be more like moving all DB related stuff to Dao Classes > and maybe rename the Management Classes with a different naming > strategy/pattern. > > I don't think we need an Interface for each and every "Impl" at this > point. The Interfaces where needed in the past for usage in Spring Beans > when you are using the XML based Dependency Injections with Spring and > template approach to "inject" the Hibernate/OpenJPA session. The > "AutoWired" Spring feature does not need those Interface Classes. So I see > no need to create an Interface for every DaoImpl at this point. > I agree, maybe it make sense to rename them to be just DAO? > > Sebastian > > 2012/4/12 Maxim Solodovnik <[email protected]> > >> I agree, >> Resolving 1.c will improve our Oracle support (we do not fit Oracle >> limitations because of long auto-increment fields) >> >> I would add >> 1.d) we have multistile DB table naming like appointmentremindertyps, >> room_poll_answers, I think is is good idea to unify them (and probably make >> shorter) >> >> 1.e) All data beans need to be unified to have "automatic references" to >> related objects like >> MeetingMember.meetingMemberId should be reference to internal object not >> just Long. >> >> 1.f) Currently we have *DaoImpl and *management working with DB (calling >> EntityManager directly) I see inconsistencies in this. >> a) we have *DaoImpl but do not have *Dao (usually we have Interface >> *Dao, and 1 or more implementations *DaoImpl) >> b) I fill we need to separate DB layer i.e. move all work with >> database to DAOs, and remove such work from management objects, this will >> reduce similar functionality and makes code more consistent. >> >> I think we need to review our services list and make them more >> consistent. Maybe separate "red5" services to separate package. >> >> 2012/4/11 [email protected] <[email protected]> >> >> Backup files are XML files. The relation between XML file and database >>> schema is not 1:1. The XML files are more like an aggregation of multiple >>> tables that represent together an object. >>> >>> It would be another idea to generate the code for the "XML BackupFile >>> Export and Importer" Java Classes directly from the Persistence Beans. >>> _Then_ we would have a direct relation between database schema and backup. >>> Anyhow ... this might be also a point for our future roadmap: Automatic >>> Code generator for Export/Import functionality based on persistence beans. >>> >>> >>> Sebastian >>> >>> 2012/4/11 Alexei Fedotov <[email protected]> >>> >>>> If backup file structure won't change, great. >>>> >>>> -- >>>> With best regards / с наилучшими пожеланиями, >>>> Alexei Fedotov / Алексей Федотов, >>>> http://dataved.ru/ >>>> +7 916 562 8095 >>>> >>>> >>>> >>>> 2012/4/11 [email protected] <[email protected]>: >>>> > Schema changing has no affect on update process. >>>> > Update process is: >>>> > export backup file, >>>> > install in blank database >>>> > import backup file >>>> > >>>> > There should be no problem as long as we stay with that process. >>>> > >>>> > Sebastian >>>> > >>>> > 2012/4/11 Alexei Fedotov <[email protected]> >>>> > >>>> >> Changing schema would likely affect update process. That should not >>>> stop us >>>> >> from moving forward, but worth additional effort planning. >>>> >> 11.04.2012 13:44 пользователь "[email protected]" < >>>> >> [email protected]> >>>> >> написал: >>>> >> >>>> >> > Hi, >>>> >> > >>>> >> > I would like to start some discussion about our overall RoadMap on >>>> our >>>> >> > System architecture for the mid and long term. >>>> >> > This is not intend to be realized for the 2.0 release but I think >>>> there >>>> >> is >>>> >> > need to find some consens on the overall direction. >>>> >> > >>>> >> > *1) Database Schema* >>>> >> > There is some inconsistencies (or maybe it is just Non-Standard >>>> >> compliant) >>>> >> > in the database schema, that have kind of historical reasons: >>>> >> > >>>> >> > A) The tables have a column "deleted" with type Varchar >>>> >> > The reasone was that some tables where many-to-one relations that >>>> where >>>> >> > build by hibernate ORM mapping. In those many-to-one mappings you >>>> could >>>> >> > define a where-clause. The problem with that where-clause was/is >>>> that you >>>> >> > could not define a where clause based with boolean attributes in >>>> >> annotions. >>>> >> > So that is why the column "deleted" is a string instead of a >>>> boolean.I >>>> >> > think in openJPA there is currently the same problem. However we >>>> can use >>>> >> > NamedQueries instead. >>>> >> > >>>> >> > B) Many-to-many tables contain attributes >>>> >> > The purpose of the table "organization_users" is only to hold a >>>> relation >>>> >> > between users and organizations. In a clean database scheme that >>>> table >>>> >> > would only contain two attributes: user_id and organization_id. >>>> There >>>> >> would >>>> >> > be not even a Java-Bean in our business logic layer. The User >>>> Object >>>> >> would >>>> >> > directly contain a List of Organizations. The problem here is that >>>> we >>>> >> > define an attribute "is_moderator" in the mapping table. The >>>> attribute's >>>> >> > meaning is to make an user a moderator of single organizations >>>> instead of >>>> >> > giving globally system wide moderation rights. >>>> >> > I think making a table "organzation_user_properties" and putting >>>> into >>>> >> that >>>> >> > table the "is_moderator" attribute would be the standard way to >>>> solve it. >>>> >> > There are some client side related issues if we move the >>>> Organization >>>> >> List >>>> >> > directly in the User object instead like it is now: User > >>>> Org_user > >>>> >> > Organization. >>>> >> > Same for "rooms_organizations". But it should be easier here as >>>> there are >>>> >> > no attributes in the mapping table to clean it up to a standard >>>> schema. >>>> >> > >>>> >> > C) Change annotations for primary keys to use the column "id" >>>> >> > I think we should make all our tables (except "meetme" because >>>> Asterisk >>>> >> > requires it that way) to have the primary key column name "id" >>>> instead of >>>> >> > for example "organization_id". I think we can change that in our >>>> ORM >>>> >> layer >>>> >> > only, no need to rename every attribute in the Java objects. >>>> >> > >>>> >> > *2) DTOs instead of using persistence objects in the Client-Server >>>> >> > communication* >>>> >> > It was so far quite handy: If you wanted a new attribute for >>>> example in >>>> >> the >>>> >> > User Object you just changed the Mapping files, and directly all >>>> client >>>> >> > side objects also have that attribute. Quite handy to get things >>>> done >>>> >> fast. >>>> >> > However it will turn out that in our future our system will become >>>> hard >>>> >> to >>>> >> > maintain if we keep it that way. Every change in the persistence >>>> layer >>>> >> will >>>> >> > need changes on the client side. That will make it hard to improve >>>> >> certain >>>> >> > components or modules as you can't do it without changing/knowing >>>> the >>>> >> whole >>>> >> > framework. >>>> >> > We should try to separate the persistance beans from the data >>>> transport >>>> >> > beans (DTO). >>>> >> > That would mean we define Objects that contain exactly the >>>> information >>>> >> that >>>> >> > is needed in the client for each RPC call. In reality that will of >>>> course >>>> >> > mean that we will have in the beginning almost a 1:1 copy of the >>>> >> > persistence beans as DTOs. However the goal should be first to >>>> find a >>>> >> good >>>> >> > mechanism to convert persistence beans to DTOs without spending >>>> too much >>>> >> > time and effort on marshalling an object from persistence to >>>> transport >>>> >> > bean. >>>> >> > By doing that we will give client side developers a more stable >>>> API. Our >>>> >> > SOAP / REST API already contains a lot of API calls that only stay >>>> there >>>> >> > because of backwards compatibility. We have to do something here >>>> to make >>>> >> > our API more stable and still beeing able to do major changes in >>>> the >>>> >> core. >>>> >> > >>>> >> > I don't think that those points will go into Apache OpenMeetings >>>> 2.0 >>>> >> > Release (except 1) C ) but maybe for a Release 3.x >>>> >> > >>>> >> > Thoughts on that? >>>> >> > There are other points that should be added here? >>>> >> > >>>> >> > Sebastian >>>> >> > >>>> >> > -- >>>> >> > Sebastian Wagner >>>> >> > https://twitter.com/#!/dead_lock >>>> >> > http://www.openmeetings.de >>>> >> > http://www.webbase-design.de >>>> >> > http://www.wagner-sebastian.com >>>> >> > [email protected] >>>> >> > >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Sebastian Wagner >>>> > https://twitter.com/#!/dead_lock >>>> > http://www.openmeetings.de >>>> > http://www.webbase-design.de >>>> > http://www.wagner-sebastian.com >>>> > [email protected] >>>> >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.openmeetings.de >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> [email protected] >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.openmeetings.de > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] > -- WBR Maxim aka solomax
