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]
