Hi, I would give this proposal a +1 if we have a name to assign to the QA task that is necessary to keep the pstgresql script. Looking forward to see the JPA stuff do his work. Nils
Am 16.01.2012 um 09:17 schrieb Tobias Wunden: > 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] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
