Take me over?
NAME
Alzabo::Runtime::Schema - Schema objects
SYNOPSIS
use Alzabo::Runtime::Schema qw(some_schema);
my $schema = Alzabo::Runtime::Schema->load_from_file( name => 'foo' );
$schema->set_user( $username );
$schema->set_password( $password );
$schema->connect;
DESCRIPTION
This object can only be loaded from a file. The file is created whenever a corresponding Alzabo::Create::Schema object is saved.
INHERITS FROM
Alzabo::Schema
METHODS
load_from_file
Loads a schema from a file. This is the only constructor for this class.
Parameters
name => $schema_name
Returns
An Alzabo::Runtime::Schema
object.
Throws
user
Returns
The username used by the schema when connecting to the database.
set_user ($user)
Set the username to use when connecting to the database.
password
Returns
The password used by the schema when connecting to the database.
set_password ($password)
Set the password to use when connecting to the database.
host
Returns
The host used by the schema when connecting to the database.
set_host ($host)
Set the host to use when connecting to the database.
referential_integrity
Returns
A boolean value indicating whether this schema will attempt to maintain referential integrity.
set_referential_integrity ($boolean)
Sets the value returned by the referential_integrity
method. If true, then when Alzabo::Runtime::Row
objects are deleted, updated, or inserted, they will report this activity to any relevant Alzabo::Runtime::ForeignKey
objects for the row, so that the foreign key objects can take appropriate action.
Defaults to false.
connect (%params)
Calls the Alzabo::Driver->connect
method for the driver owned by the schema. The username, password, and host set for the schema will be passed to the driver, as will any additional parameters given to this method. See the Alzabo::Driver->connect
method for more details.
join
Join tables is done by taking the tables provided, in order, and finding a relation between them. If any given table pair has more than one relation, then this method will fail. The relations, along with the values given in the optional where clause will then be used to generate the necessary SQL. See Alzabo::Runtime::JoinCursor
for more information.
NOTE: This method is currently considered experimental.
Parameters
tables =>
Alzabo::Runtime::Table
object or objectsThe tables being joined together. The order of these tables is significant if there are more than 2 tables, as we expect to find relationships between tables 1 & 2, 2 & 3, 3 & 4, etc.
This can be either a single table or an array reference of table objects.
select =>
Alzabo::Runtime::Table
object or objects (optional)This parameter specifies from which tables you would like rows returned. If this parameter is not given, then the tables parameter will be used instead.
This can be either a single table or an array reference of table objects.
where
See the documentation on where clauses for the Alzabo::Runtime::Table class.
order_by
See the documentation on order by clauses for the Alzabo::Runtime::Table class.
limit
See the documentation on limit clauses for the Alzabo::Runtime::Table class.
Returns
If the select
parameter (or tables
parameter) specified that more than one table is desired, then this method will return an Alzabo::Runtime::JoinCursor
object representing the results of the join. Otherwise, the method returns an Alzabo::Runtime::RowCursor
object.
Throws
USER AND PASSWORD INFORMATION
This information is never saved to disk. This means that if you're operating in an environment where the schema object is reloaded from disk every time it is used, such as a CGI program spanning multiple requests, then you will have to make a new connection every time. In a persistent evironment, this is not a problem. In a mod_perl environment, you could load the schema and call the set_user
and set_password
methods in the server startup file. Then all the mod_perl children will inherit the schema with the user and password already set. Otherwise you will have to provide it for each request.
You may ask why you have to go to all this trouble to deal with the user and password information. The basic reason was that I did not feel I could come up with a solution to this problem that was secure, easy to configure and use, and cross-platform compatible. Rather, I think it is best to let each user decide on a security practice with which they feel comfortable. If anybody does come up with such a scheme, then code submissions are more than welcome.
CAVEATS
Refential Integrity
If Alzabo is attempting to maintain referential integrity and you are not using either the Alzabo::ObjectCache
or Alzabo::ObjectCacheIPC
module, then situations can arise where objects you are holding onto in memory can get out of sync with the database and you will not know this. If you are using one of the cache modules then attempts to access data from an expired or deleted object will throw an exception, allowing you to try again (if it is expired) or give up (if it is deleted). Please see Alzabo::ObjectCache
for more details.
AUTHOR
Dave Rolsky, <autarch@urth.org>