Speaking only for myself, I believe is right to continuing supporting Oracle, if only due to the current install base.
CC On Mon, May 3, 2010 at 4:09 PM, Maxim Burgerhout <[email protected]> wrote: > PostgreSQL support would really mean a lot to me and I dont think > alone. Please do not drop this. > > I understand it is hard to port the database from Oracle to PostgreSQL > (as it is a huge schema), but at my company we were highly > anticipating the future migration to PostgreSQL. We were really very > happy when it was announced PostgreSQL would be supported in a future > release. I mean, wasn't the embedded Oracle database one of the > reasons for Satellite's relatively high price tag? And PostgreSQL > being open source was a big plus, too. > > Sadly, I do not have the resources, nor the knowledge to do the > porting myself. Maybe the guys at EnterpriseDB (I think I remember Red > Hat partnering with them recently) could make a showcase project out > of this? To show how good PostgreSQL can do the work of an Oracle > database? > > Given the size of the schema, migrating to PostgreSQL from Oracle > instead of supporting both might be the only option if conversion > tools do not work well enough. Moving to PostgreSQL entirely would > have it's own complicated demands outside of the schema too, though. > Most large Red Hat-based deployments have pretty large Oracle clusters > too. If Satellite is regarded as mission critical and the database is > hosted on one of those Oracle clusters, dropping Oracle support might > make them slightly annoyed. And adding optional built-in redundancy > for PostgreSQL surely is complicated. > > Maxim Burgerhout > [email protected] > ---------------- > GPG Fingerprint > EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A > > > > On Fri, Apr 30, 2010 at 18:12, Travis Camechis <[email protected]> wrote: >> I agree it would be nice to not have to worry with oracle at all but I think >> people still would like to have the option and there are many people already >> using oracle in there spacewalk environment. >> >> On Fri, Apr 30, 2010 at 11:46 AM, Kevin Fox <[email protected]> wrote: >>> >>> On Fri, 2010-04-30 at 01:22 -0700, Miroslav Suchý wrote: >>> > On 04/29/2010 11:57 PM, James Hogarth wrote: >>> > > Hi all, >>> > > >>> > > Great to see the 1.0 milestone reached. Friday afternoons in my team >>> > > we assign to 'personal projects' and I've been thinking about trying >>> > > to help with the postgres side of things during this time I have >>> > > 'free'. >>> > > >>> > > The pgsql head in git hasn't had a commit in 9 months... is this even >>> > > valid anymore? >>> > >>> > Well... So what is status of PostgreSQL in Spacewalk? >>> > Yes, no one touched it for 9 months. We had other priorities. >>> > >>> > But anyway, what we have now: >>> > We partially convert our initial schema. >>> > There is some tool called Chameleon: >>> > https://fedorahosted.org/chameleon >>> > which was written by Jeff Ortel specially for Spacewalk. Chameleon can >>> > translate Oracle schema to PostgreSQL schema. But it is far from >>> > perfect. First - it is completely undocumented. Second - it can not >>> > translate everything. Just look at schema/spacewalk/postgres/manual/* >>> > how many things are converted manually. >>> > And maintaing two sets of SQLs schemas is no way. This will not work. >>> >>> I understand the complexities of maintaining two schemas. Just to throw >>> this idea out there, assuming the postgres backend was good enough, why >>> bother with the oracle one at all? Redhat usually focuses pretty hard at >>> having their open source projects only depend on other open source >>> projects. Or at very least, only optionally depend on the closed ones. >>> The effort could be spent porting to postgres once and drop oracle >>> support instead of trying to constantly convert code written for the >>> closed source oracle's sql to postgres. >>> >>> Kevin >>> >>> >>> > So >>> > we need something that will be able to translate *everything*. If it >>> > will be enhanced Chameleon or we start from scratch (e.g. by writing >>> > rules for good old sed) - that is question... >>> > >>> > And we just focused on initial schema for now. No one looked on SQL >>> > queries in our code. How do we (automatically) translate it to >>> > postgresql? Some queries are separated from code (hbm.xml) some are >>> > still in middle of the code. How we will handle this? What is the best >>> > way? How this all affect speed of code? Then there are some >>> > infrastructural changes which should be probably done prior finishing Pg >>> > support. >>> > >>> > A lot of question. We should decide some design questions, before we >>> > start coding. >>> > >>> > If you really want to help. You can take a look on Chameleon and >>> > investigate if it is worth of continuing in it and write some >>> > documentation for it. >>> > >>> > Or you can start with some simple Spacewalk bugs and first get overview >>> > of Spacewalk internals, before you start with more complex task, which >>> > Pg support is for sure. >>> > >>> > Or you can do some review of Spacewalk packages for Fedora: >>> > https://bugzilla.redhat.com/show_bug.cgi?id=F-Spacewalk >>> > >>> > Or anything else. But jumping directly on Pg support as you first >>> > contribution is probably not good idea. >>> > >>> >>> >>> _______________________________________________ >>> Spacewalk-devel mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/spacewalk-devel >> >> _______________________________________________ >> Spacewalk-devel mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/spacewalk-devel >> > > _______________________________________________ > Spacewalk-devel mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-devel > -- RHCE#805007969328369 _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
