database

Hi all,
i'am one of the guys who is triyng to build an oracle driver for drupal.... (http://drupal.org/project/oracle)
I actually wrote 2 drivers: 1 for the 6.x and 1 for the 7.x. Both based on PDO_OCI, and both working pretty
well with the core, (i'am still working on the 7.x SimpleTest test cases but 90% is ok).

I started using the 6.x driver in production on February (when it was on sourceforge.net as drupaloracle).

A couple of days a go, one of my company web developers, told me:

"Hey.. we should use this X module.... It is cool!"

I have been asked to create a database for proposal teams to see what small spacecraft components and techniques are available at Ames. The database will also be used by directors to see the general trends that will inform changes in facilities, investment, and other planning issues.

Hello Everyone,

I have a website with 100k Visitors/Day , I am a newbie in Php and Servers, when a downtime occurs managed hosting guy was resetting the server and I was optimizing the databases and I was optimizing the DB everyday and I was fine.

But this week site became to crash twice a day. And Reboot/optimize only works for 5-6 hrs and it crashes again. My hosting guy said it is caused by cache_page table in mySQL and it gives ~300MiB overhead in 2hrs after mysql optimization. And he said its a wrong method to keep cache in database it causes this errors.

I just installed the DB maintenance module (version 6.x-1.1) and am following chapter 15 in Bill's book. I noticed that it doesn't give the options to back up the database as illustrated on p. 340.

Some searching turned up that version 2.1 (in both 5 and 6) have this capability. 2.1 for D6 is in beta. I would love the functionality but don't want to break anything. Any suggestions?

With Drupal 6, menu tokens are able to automatically load database records given an object id, this is a great feature, however this requires developers to implement 'load functions' for loading their records. Those 'load functions' are often just a wrapper around 'SELECT * from {mytable} WHERE mykey = %d'.

We could do better, and allow automatically load operations, and even better, enable automatic basic CRUD.

I've already read the discussion about D5 Shared database but didn't find a resumed classification for D6

Knowing which tables to share can be hard to figure out, so I would like some help on this.

The scenario:
- Intranet services developed by different individual which shouldn't interfere each other (so each developer has one D6 sandbox for each service which shouldn't interfere with others)
- Global user/roles/permission settings
- Modules/Themes can (probably will) differ from service to service

I have a custom module I inherited that implements its own CCK widgets to import videos, and the widget stores multiple columns in the database, but to the user, it all seems like one field.

I recently decided we needed to add a column to refer to the thumbnail, so I edited my 'database columns' operation in the hook_field_settings() function, and added a line in the hook_field() function, along with the logic I needed to fetch, display and validate the data.

After investing a lot of time trying to figure out how to do multi-site via a shared database, I've come to the following (personal opinion) conclusion.

Just Say No

Reasons:

Warning - I'm a noob, please be gentle

Here's a pretty much self-documented settings.php file showing how I've got my multi-site working. If someone familiar with Drupal's (v5) database structures could scan this and comment I'd really appreciate it. Note ALL the core tables are listed here, as per grepping "CREATE TABLE" from the .install files.


$db_prefix = array(
'default' => 'watchout_drupal.shb1sh_', /* new tables get created here, /
/ need to analyze and then add (shared or separate?) below /
'cache' => 'shb1sh_', / must be separate /
'cache_filter' => 'shb1sh_', / must be separate /
'cache_menu' => 'shb1sh_', / must be separate /
'cache_page' => 'shb1sh_', / must be separate /
'variable' => 'shb1sh_', / must be separate /
'accesslog' => 'shb1sh_', / site tracking - separate /
'client' => 'shb1sh_', / site tracking - separate /
'client_system' => 'shb1sh_', / site tracking - separate /
'flood' => 'shb1sh_', / site tracking - separate /
'watchdog' => 'shb1sh_', / site tracking - separate

I've come up against a usability problem that I think is caused by a problem in Drupal's data model.

Example of problem: When setting block visibility settings, it is impossible (without writing custom php), to make a block visible to authenticated users who have no other role, if you don't want that block to show to all authenticated users. In other words, you may want to show the block to all authenticated users except those of belonging to role x. No can do without php.