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] >
