Database
Last Modified: August 11, 2003 00:08AM
|
|
(Any)
|
Description
Mantis uses MySQL for it's database needs. Other database support will follow in future versions (see Roadmap for details).
If you have any comments on the Mantis database design, please feel free to share your view through the Mantis developers mailing list, or bug submitting a bug to our bugtracker.
Porting
This project has a stated goal of database independence. Unfortunately, even with a database abstraction packages, this is a rather large task. More than just the access mechanisms need to be available. The table data and query behaviors also need to be emulated correctly. Work will be devoted to this in the future.
As a true database, MySQL is severly lacking in core features, however, in our case it is sufficient. Just remember to backup your database every few days.
One of the unforseen benefits of using MySQL is that most of the SQL is very simple. There are no SUB-SELECTS, no foreign keys, no stored procedures. Porting efforts should be relatively simple. Here are some of the key points that require attention in porting efforts.
Basic database functions
- db_connect()
- db_select_db()
- db_query()
- db_result()
- db_num_rows()
- db_fetch_array()
- db_insert_id()
- db_close()
Some notes:
- AUTO_INCREMENT - There must be a method for generating a unique id for every entry in a table. Oracle uses SEQUENCES and TRIGGERS.
- LAST_INSERT_ID() - There needs to be a database mechanism to retrieve the ID of the record that was just inserted. There are several places in Mantis where multiple inserts take place in one script and each script needs the ID of the previously inserted record. MSSQL uses something like "SELECT @@IDENTITY AS 'id'" to accomplish this. Oracle uses the SEQUENCE's currval field.
- count selected rows - Mantis uses mysql_num_rows() to get this number. An alternative is to return a COUNT(*) in a SQL query. The COUNT(*) method should work on most databases.
- Transactions - Most databases support transactions except for MySQL. A support mechanism needs to be built to accomodate MySQL.
- Dates are handled differently on differnt databases. Code and queries must be carefully crafted to minimize date specific operations.
Database Abstraction Libraries
Our support for multiple DBMSes will be through the use of a database abstraction library. Following are the ones we will consider:
|
User Contributed Notes
Database |
|
wojtek@voyteck.pl
24-Nov-2003 6:50 |
#27
|
| If your MySQL accepts socket connections through the non-default socket (in /tmp/...) type into $g_port your socket path - will also work. |
|
amaso@gadgetbear.com
04-Dec-2003 16:16 |
#32
|
Is there any risk in entering my SQL database password in the configuration file? Can someone who knows something about PHP read the file and do (bad?) stuff with my datgabase?
---
[Editor] Following are the cases (that I can think of) where you password may be exposed:
- PHP Server gets uninstalled from the Web Server (or was not installed in the first place).
- Other users have access to the Mantis directory through FTP
- Other users have access to the Mantis directory through shell access.
- Other users have access to the Mantis directory through LAN. |
|
Maarten
13-Dec-2003 6:25 |
#35
|
In a normal situation, people cannot see the sourcecode of your PHP-pages, because it is parsed by your server before the page is returned to a browser.
Only if your PHP-parser has problems and gets disabled, people who know the URL of your config_inc.php file can see the contents.
To the developers: Why don't you create an option so that users can specify the path to config_inc.php? I'd like mine above the HTDOCS root... Pretty save I guess.
---
[Editor] This will require another config_inc to point to the config_inc! This complicates things without a practical benefit. |
|
mantis-doc.to.skeeve@spamgourmet..com
23-Jan-2004 0:29 |
#58
|
So why not configure in config.inc the location of the password file?
You can keep that out of HTDDOCS then. |
|
|
|
| Last updated: Fri, 12 Mar 2010 - 14:41:22 |
|
|
