Hi, maybe we can bring this discussion to an end by making sure everyone involved is on the same plate in terms of the technical situation.
>From my point of view, the interesting question is: why do we have ddl scripts >for two database servers when we are using JPA (java persistence api) to >access the databases? Some of you will know that JPA abstracts from individual >database servers and transforms schema setup and querying/updating/deleting >into native statements for each of the supported databases. So you may be >thinking that the ddl scripts must be obsolete. Well, almost true! With the >current version of JPA that we use, there is no support for the creation of >database indices, which is critcal for databases with larger amounts of data. >Support for index annotations and creation comes with more recent versions of >JPA, but there are also issues that need to be solved (OSGI-ready versions of >datasources need to be used instead of plain jdbc drivers). As a conclusion, as soon as we switch to a more recent version of JPA (and are able to resolve the issues that come with that transition) we should be compatible with every database supported by JPA, and there is no need for us as a community to maintain database specific ddl scripts anymore. Therefore my proposal: let's keep the existing ddl scripts (mysql and postgresql) up to date for 1.3 and then move to JPA 2.2 or later to finally get rid of those scripts. Tobias On 12.01.2012, at 00:31, [email protected] wrote: > Hi, > >> Why support MySQL over postgresql when MySQL is tied to Oracle and its >> potential licensing issues? Already Oracle is adding features that were >> originally going to be in the release as for pay only. It would be much >> better to go with a community owned dbms imho. > > MySQL is GPL with an OSI-approved waiver for non GPL'ed but open source > projects, so I don't see an issue with our continued use of it. > > To be honest, I don't care much, I'm just much more familiar with MySQL and > their management tools. If there were strong opposition on the grounds that > the proposal has MySQL in it then we could change it. The goal isn't to > eradicate support for Postgres, but to push the burden for that support onto > people who are willing to offer it, and limit the amount of testing we need to > do for each release. > > (I think it's pretty unreasonable that we're not testing fully on both mysql > and > postgres given that we're suggesting either could be used, so lets just say > that > support for postgres is there but maintained by the community and not part of > our regular QA process. Otherwise I think we need to maintain QA platforms > for > both mysql and postgres, which is a pain and not fruitful with the resources > we > have.) > > Chris > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
