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]
