Additionally I would: 1) modify Fieldvalues class and make fieldvalues_id column NOT Generated value 2) connect Fieldvalues with Fieldlanguagesvalues and FieldLanguage 3) add mechanism allowing to get english value for the string if there no such string in the language
implementing 1) will allow easier develop OM extentions: extension strings can have string ids starting 100000 and this will make upgrade easier. On Sat, Apr 14, 2012 at 7:35 PM, Maxim Solodovnik <[email protected]>wrote: > 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 > -- WBR Maxim aka solomax
