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]
