Alzabo::Runtime::Schema - Schema objects |
Alzabo::Runtime::Schema - Schema objects
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;
This object can only be loaded from a file. The file is created whenever a corresponding Alzabo::Create::Schema object is saved.
Alzabo::Schema
Note: all relevant documentation from the superclass has been merged into this document.
Loads a schema from a file. This is the only constructor for this class.
An Alzabo::Runtime::Schema
object.
The username used by the schema when connecting to the database.
Set the username to use when connecting to the database.
The password used by the schema when connecting to the database.
Set the password to use when connecting to the database.
The host used by the schema when connecting to the database.
Set the host to use when connecting to the database.
A boolean value indicating whether this schema will attempt to maintain referential integrity.
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.
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.
Joins are 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.
Alzabo::Runtime::Table
object or objectsThis can be either a single table or an array reference of table objects.
Alzabo::Runtime::Table
object or objects (optional)This can be either a single table or an array reference of table objects.
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.
Joins are done by taking the tables provided, in order, and finding a
relation between them, excluding the last table given. 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.
Alzabo::Runtime::Table
object or objectsFor example, given the tables 'foo', 'bar', 'baz', and 'quux', in that order, we could read this as follows. Join 'foo', 'bar', and 'baz', then do a left join between 'foo' and 'quux'.
This can be either a single table or an array reference of table objects.
An
Alzabo::Runtime::OuterJoinCursor
object. representing the results of the join.
A string containing the name of the schema.
A list of Alzabo::Runtime::Table
object named in the list
given. If no list is provided, then it returns all table objects in
the schema.
An Alzabo::Runtime::Table
object representing the specified
table.
The Alzabo::Driver
subclass object for the
schema.
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.
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.
Dave Rolsky, <autarch@urth.org>
Alzabo::Runtime::Schema - Schema objects |