From: Damien R. <dam...@me...> - 2011-08-09 16:19:40
|
Hi all, A Mantis user called DKuranov has uploaded a significant patch for Oracle DB support on the tracker [1], which according to him fixes 9 currently open issues on the subject. I'm bringing this to your attention due to all the recent talk about "next" and the changes to the DB API - I'm not sure how much of this would be reusable, and would it be worth the effort to implement it in 1.2.x. Paul also mentioned (or rather, implied) dropping support for some DB's including oracle in IRC some days ago [2] - Paul94 i'd like to see mantis support Paul94 a) mysql Paul94 b) postgres Paul94 c) sqlsrv aka mssql Paul94 d) sqlite Damien [1] http://www.mantisbt.org/bugs/view.php?id=13227 [2] http://www.mantisforge.org/irclogs/%23mantishelp.2011-07-26.log.html |
From: Robert M. <rob...@gm...> - 2011-08-09 16:23:39
|
On Tue, Aug 9, 2011 at 7:14 PM, Damien Regad <dam...@me...> wrote: > Hi all, > > A Mantis user called DKuranov has uploaded a significant patch for > Oracle DB support on the tracker [1], which according to him fixes 9 > currently open issues on the subject. > > I'm bringing this to your attention due to all the recent talk about > "next" and the changes to the DB API - I'm not sure how much of this > would be reusable, and would it be worth the effort to implement it in > 1.2.x. > > Paul also mentioned (or rather, implied) dropping support for some DB's > including oracle in IRC some days ago [2] - Why would we want to drop support for Oracle? I can offer support and testing, although I do not use MantisBT on Oracle myself. All in all I think the effort is not too great once we sort out the initial issues. And there clearly is interest in MantisBT being used with Oracle. Robert > > Paul94 i'd like to see mantis support > Paul94 a) mysql > Paul94 b) postgres > Paul94 c) sqlsrv aka mssql > Paul94 d) sqlite > > Damien > > > [1] http://www.mantisbt.org/bugs/view.php?id=13227 > [2] http://www.mantisforge.org/irclogs/%23mantishelp.2011-07-26.log.html > > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- Sent from my (old) computer |
From: Victor B. <vi...@fu...> - 2011-08-09 16:34:58
|
+1 for keeping Oracle support. With the move to Git, having contributor(s) who can validate, + github simplicity, we should be able to maintain it. It will be as good as the contributors make it. On Tue, Aug 9, 2011 at 9:23 AM, Robert Munteanu <rob...@gm...>wrote: > On Tue, Aug 9, 2011 at 7:14 PM, Damien Regad > <dam...@me...> wrote: > > Hi all, > > > > A Mantis user called DKuranov has uploaded a significant patch for > > Oracle DB support on the tracker [1], which according to him fixes 9 > > currently open issues on the subject. > > > > I'm bringing this to your attention due to all the recent talk about > > "next" and the changes to the DB API - I'm not sure how much of this > > would be reusable, and would it be worth the effort to implement it in > > 1.2.x. > > > > Paul also mentioned (or rather, implied) dropping support for some DB's > > including oracle in IRC some days ago [2] - > > Why would we want to drop support for Oracle? I can offer support and > testing, although I do not use MantisBT on Oracle myself. All in all I > think the effort is not too great once we sort out the initial issues. > And there clearly is interest in MantisBT being used with Oracle. > > Robert > > > > > Paul94 i'd like to see mantis support > > Paul94 a) mysql > > Paul94 b) postgres > > Paul94 c) sqlsrv aka mssql > > Paul94 d) sqlite > > > > Damien > > > > > > [1] http://www.mantisbt.org/bugs/view.php?id=13227 > > [2] http://www.mantisforge.org/irclogs/%23mantishelp.2011-07-26.log.html > > > > > > > ------------------------------------------------------------------------------ > > uberSVN's rich system and user administration capabilities and model > > configuration take the hassle out of deploying and managing Subversion > and > > the tools developers use with it. Learn more about uberSVN and get a free > > download at: http://p.sf.net/sfu/wandisco-dev2dev > > _______________________________________________ > > mantisbt-dev mailing list > > man...@li... > > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > > > > -- > Sent from my (old) computer > > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: David H. <d...@hx...> - 2011-08-11 10:55:05
|
On Tue, 2011-08-09 at 09:34 -0700, Victor Boctor wrote: > +1 for keeping Oracle support. With the move to Git, having > contributor(s) who can validate, + github simplicity, we should be > able to maintain it. It will be as good as the contributors make it. At the moment we have significant issues with MantisBT (particularly the installation and upgrade steps) on PostgreSQL, Oracle, MSSQL and a bunch of minor database servers too. This is why a lot of work has gone into rewriting database support in the 'next' branch. The idea is to use PDO for parametrised queries, using strict SQL:2008 compliant queries in the source code. If a particular database server doesn't meet SQL:2008 then we rewrite queries (on a per-database-server basis) to match the custom/non-compliant syntax expections. Most MantisBT queries are very simple and are supported by all SQL server software. However schema definitions and a few complex queries will be quite different between servers. The rewriting step is till TBC and some of the ideas put forward so far include: 1) Use Doctrine DBAL (separate from their ORM) 2) Have a lookup table for queries, much like our current language system I recon we'll need (2) regardless of whether we pick up (1). This would catch any edge cases where we need maximum flexibility over rewriting a query for a particular database backend. There are some fairly complex issues that need investigating such as whether we could use PostgreSQL's full text search features (tsvector, tsquery, etc) to _dramatically_ improve search performance while also maintaining support for less feature packed servers. I think what Paul's quoted comment refers to not having any clear indication of which database servers are being used and tested by developers/users. We should be able to support an Oracle database backend. But do we have enough people willing to support and test it? If the answer is no, we shouldn't be advertising that support. Regards, David |
From: Damien R. <dam...@me...> - 2011-08-11 11:44:55
|
Thanks for the comments On 08/11/2011 12:57 PM, David Hicks wrote: > We should be able to support an Oracle database > backend. But do we have enough people willing to support and test it? > If the answer is no, we shouldn't be advertising that support. I think that's the key. Considering that Robert mentioned being able to offer support and testing, I think we should be covered. I may be able to help too, as I have some Oracle DB's here, but I'd need to convince the DBA team to give me a schema for testing first, and then somehow setup Oracle client on my Ubuntu (I tried a while ago and did not succeed) :-/ Anyway, the questions: 1. Do we implement the DKuranov fixes to hopefully have Oracle working without end-user tweaks in 1.2.x ? (I think it would be a good idea) 2. Is it then worth porting the changes to 1.3.x now ? (Depends whether "next" replaces 1.3 or comes later, I guess) I can put the changes up on github for review & test. Damien |
From: David H. <d...@hx...> - 2011-08-11 12:00:28
|
On Thu, 2011-08-11 at 13:40 +0200, Damien Regad wrote: > 1. Do we implement the DKuranov fixes to hopefully have Oracle working > without end-user tweaks in 1.2.x ? (I think it would be a good idea) If those changes: 1) Have been tested against MySQL, PostgreSQL, etc and don't cause breakages 2) Don't change the database schema in any way 3) Don't rewrite massive chunks of MantisBT in a way that could change how MantisBT 1.2.x works for people (bugs or otherwise) Then yes. Otherwise we need to look at taking those ideas and reimplementing them in 'master', preferably using Paul's work on implementing a new database layer to MantisBT (see the 'next' branch as well as Paul's own 'db' branch on Github). > 2. Is it then worth porting the changes to 1.3.x now ? (Depends whether > "next" replaces 1.3 or comes later, I guess) It wouldn't help by placing these changes in 'master' at the moment. The reason being that we'll just have to remove them prior to merging the 'next' branch (or whatever other attempt we put together for rewriting MantisBT database support). I think we need to focus on finishing Paul's database rewrite so that we have a modern and robust starting point for supporting Oracle, MSSQL, PostgreSQL, etc properly again. I recall that Oracle imposes a number of restrictions such as maximum field lengths... these are issues that are very hard and messy to fix with our current database API. With a new database API though - it would be a lot more straightforward to fix. Regards, David |
From: David H. <d...@hx...> - 2011-08-11 12:02:09
|
On Thu, 2011-08-11 at 22:03 +1000, David Hicks wrote: > I recall that Oracle imposes a number of restrictions such as maximum > field lengths... Correction: I meant to refer to maximum lengths of column names. |
From: Damien R. <dam...@me...> - 2011-08-11 17:47:51
|
On 08/11/2011 02:03 PM, David Hicks wrote: > On Thu, 2011-08-11 at 13:40 +0200, Damien Regad wrote: >> 1. Do we implement the DKuranov fixes to hopefully have Oracle working >> without end-user tweaks in 1.2.x ? (I think it would be a good idea) > > If those changes: > 1) Have been tested against MySQL, PostgreSQL, etc and don't cause > breakages I uploaded the experimental branch to github. Have not had opportunity to do any tests (can't with Oracle anyway), but as I'll be away for 2 weeks I thought I'd give everyone a chance to have a look. > 2) Don't change the database schema in any way Does not any more, I fixed that from the original patch. > 3) Don't rewrite massive chunks of MantisBT in a way that could change > how MantisBT 1.2.x works for people (bugs or otherwise) I don't think so, but I'm not as experienced as some of you guys. Please have a look and tell me if otherwise. Damien |