schema

lbourn's picture

raSANTIAGO scripts: stuck on something

I'm trying to deal w/ script "2_person_groups.sql" and I'm having a devil of a time getting through parts of this one (and I'm sure it'll happen again later on too).

I don't understand why there's a line CONCAT("Facil import: tblPerson.PersonID=", PersonID)   AS description, -- it seems to me that this pulls in a user ID number from a member and uses it as the group description. But that line makes sense in a subsequent script, so I think it might be an error due to copy and paste.

Also, the script doesn't work, at least for me at Boston.

Read more
recidive's picture

Simple object CRUD: a proposal

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.

Read more
HansBKK's picture

D5 Shared database - sharing all but theming/layout/navigation

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

Read more
scor's picture

Drupal RDF Schema proposal

I'd like to share some quick thoughts on how Drupal Data could be described in RDF. The attached schema represents the mappings between the current Drupal data structure and the proposed RDF Schema, reusing existing ontologies such as Dublin Core, FOAF, SIOC and SKOS.

The green circles represent the Drupal objects (node, revision, user, role, term), with their equivalent RDF class. The rectangles are the values used in Drupal. It's important to differentiate a class from its actual instances (resources) which are each defined by a unique URI, see the examples below. This schema is meant to be simple, incomplete, and to show the main core features.
Comment and Node are 2 different elements in Drupal, they can be combined in the same Class with the recursive property sioc:has_reply (Comment as Node). Node and Revision objects are separate here as they are in the Drupal Data structure, but they could fundamentally be merged as well.

I presented SIOC at DrupalCon Barcelona, and showed how it can be used to describe online communities. The SIOC sioc:Item class which I used here as equivalent of a Node is a broad Class with many sub-types: AddressBook, AnnotationSet, AudioChannel, BookmarkFolder, MailingList, MessageBoard, BlogPost, BoardPost, WikiArticle... See the SIOC Types Module for more details.

Read more
bjaspan's picture

Table creation order

Once foreign keys are specified during table creation, we will have to make sure to create tables in the correct order. e.g. You can't create system.schema, whose files table has a uid column, before you create user.schema which creates the users table which hold the master uid column.

If this proves too difficult we can use ALTER TABLE to put the foreign key contraints in afterward, but that seems much less desireable.

Read more
bjaspan's picture

Add join/foreign key info to schema

Now that we have four more weeks before D6 code freeze, maybe it is possible to add join relationships/foreign key support into Schema API 1 after all. Otherwise, it will be another year before this info is in core. Note that this info does not really have to be in core---it can be added by a contrib module hook_schema_alter. But a lot of people would be pretty psyched to have referential integrity for pgsql built in to D6.

Read more
drewish's picture

Additions to the API

Now that the schema has been committed to core, I wanted to open up a thread where people could discuss additions an enhancements to the API.

I posted a patch to add a db_rename_table over on #147285. I've love to see it get in before the feature freeze.

Read more
bjaspan's picture

Defining Schema data types

Now that Schema almost has a driver for PostgreSQL I needed to resolve the data type issue. I like Frando's approach (I seem to say that a lot) of storing 'type' and 'size' separately because it makes a variety of things easier. For example:

$schema['mytable'] = array(
  'cols' => array(
     'col1' = array('type' => 'int', 'size' => 'big', ...)));
Read more
bjaspan's picture

Using database schema to load nodes in fewer queries

One thing that becomes possible when Drupal can access its own database schema is that queries which currently are performed separately can instead be performed together. In particularly, I think it might be possible to load an entire node with a single SELECT query or, at least, in far fewer than Drupal currently uses. Working proof of concept code is already in the Schema module; it loads all CCK fields, comments, and author info in one query. Loading more things only requires adding a join entry to the schema data structure (see below).

Read more
bjaspan's picture

Defining the schema data structure

One of the first things we to do is define the data structure that modules will use for declaring their tables. Schema module, Frando's patch, dopry's patch, and CCK fields all use different structures though their underlying approaches are basically the same. We need to decide what kind of information the data structures must contain and can contain. This will obviously include at least columns (name, type, length, nullable, default), indices (name, columns, primary vs unique vs multi), and join/relationship information.

Read more
Subscribe with RSS Syndicate content