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
