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

       Objects in this class represent schemas, and can be used to retrieve data from that
       schema.

       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"

       Note: all relevant documentation from the superclass has been merged into this document.

METHODS

   load_from_file ( name => $schema_name )
       Loads a schema from a file.  This is the only constructor for this class.  It returns an
       "Alzabo::Runtime::Schema" object.  Loaded objects are cached in memory, so future calls to
       this method may return the same object.

       Throws: "Alzabo::Exception::Params", "Alzabo::Exception::System"

   set_user ($user)
       Sets the username to use when connecting to the database.

   user
       Return the username used by the schema when connecting to the database.

   set_password ($password)
       Set the password to use when connecting to the database.

   password
       Returns the password used by the schema when connecting to the database.

   set_host ($host)
       Set the host to use when connecting to the database.

   host
       Returns the host used by the schema when connecting to the database.

   set_port ($port)
       Set the port to use when connecting to the database.

   port
       Returns the port used by the schema when connecting to the database.

   set_referential_integrity ($boolean)
       Turns referential integrity checking on or off.  If it is on, 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.

       This defaults to false.  If your RDBMS supports foreign key constraints, these should be
       used instead of Alzabo's built-in referential integrity checking, as they will be much
       faster.

   referential_integrity
       Returns a boolean value indicating whether this schema will attempt to maintain
       referential integrity.

   set_quote_identifiers ($boolean)
       If this is true, then all SQL constructed for this schema will have quoted identifiers
       (like `Table`.`column` in MySQL).

       This defaults to false.  Turning this on adds some overhead to all SQL generation.

   connect (%params)
       Calls the "Alzabo::Driver->connect" method for the driver owned by the schema.  The
       username, password, host, and port 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.

   disconnect
       Calls the "Alzabo::Driver->disconnect()" method for the driver owned by the schema.

   join
       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.

       This method takes the following parameters:

       •   join => <see below>

           This parameter can either be a simple array reference of tables or an array reference
           of array references.  In the latter case, each array reference should contain two
           tables.  These array references can also include an optional modifier specifying a
           type of join for the two tables, like 'left_outer_join', an optional foreign key
           object which will be used to join the two tables, and an optional where clause used to
           restrict the join.

           If a simple array reference is given, then the order of these tables is significant
           when there are more than 2 tables.  Alzabo expects to find relationships between
           tables 1 & 2, 2 & 3, 3 & 4, etc.

           For example, given:

             join => [ $table_A, $table_B, $table_C ]

           Alzabo would expect that table A has a relationship to table B, which in turn has a
           relationship to table C.  If you simply provide a simple array reference, you cannot
           include any outer joins, and every element of the array reference must be a table
           object.

           If you need to specify a more complicated set of relationships, this can be done with
           a slightly more complicated data structure, which looks like this:

             join => [ [ $table_A, $table_B ],
                       [ $table_A, $table_C ],
                       [ $table_C, $table_D ],
                       [ $table_C, $table_E ] ]

           This is fairly self explanatory.  Alzabo will expect to find a relationship between
           each pair of tables.  This allows for the construction of arbitrarily complex join
           clauses.

           For even more complex needs, there are more options:

             join => [ [ left_outer_join => $table_A, $table_B ],
                       [ $table_A, $table_C, $foreign_key ],
                       [ right_outer_join => $table_C, $table_D, $foreign_key ] ]

           In this example, we are specifying two types of outer joins, and in two of the three
           cases, specifying which foreign key should be used to join the two tables.

           It should be noted that if you want to join two tables that have more than one foreign
           key between them, you must provide a foreign key object when using them as part of
           your query.

           The way an outer join is interpreted is that this:

             [ left_outer_join => $table_A, $table_B ]

           is interepreted to mean

             SELECT ... FROM table_A LEFT OUTER JOIN table_B ON ...

           Table order is relevant for right and left outer joins, obviously.

           However, for regular (inner) joins, table order is not important.

           It is also possible to apply restrictions to an outer join, for example:

             join => [ [ left_outer_join => $table_A, $table_B,
                         # outer join restriction
                         [ [ $table_B->column('size') > 2 ],
                           'and',
                           [ $table_B->column('name'), '!=', 'Foo' ] ],
                       ] ]

           This corresponds to this SQL;

             SELECT ... FROM table_A
             LEFT OUTER JOIN table_B ON ...
                         AND (table_B.size > 2 AND table_B.name != 'Foo')

           These restrictions are only allowed when performing an outer join, since there is no
           point in using them for regular inner joins.  An inner join restriction has the same
           effect when included in the "WHERE" clause.

           If the more multiple array reference of specifying tables is used and no "select"
           parameter is provided, then the order of the rows returned from calling
           "Alzabo::Runtime::JoinCursor->next()" is not guaranteed.  In other words, the array
           that the cursor returns will contain a row from each table involved in the join, but
           the which row belongs to which table cannot be determined except by examining the
           objects.  The order will be the same every time "Alzabo::Runtime::JoinCursor->next()"
           is called, however.  It may be easier to use the
           "Alzabo::Runtime::JoinCursor->next_as_hash()" method in this case.

       •   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 "distinct" or "join" parameter will be used instead,
           with the "distinct" parameter taking precedence.

           This can be either a single table or an array reference of table objects.

       •   distinct => "Alzabo::Runtime::Table" object or objects (optional)

           If this parameter is given, it indicates that results from the join should never
           contain repeated rows.

           This can be used in place of the "select" parameter to indicate from which tables you
           want rows returned.  The "select" parameter, if given, supercedes this parameter.

           For some databases (notably Postgres), if you want to do a "SELECT DISTINCT" query
           then all of the columns mentioned in your "ORDER BY" clause must also be in your
           SELECT clause. Alzabo will make sure this is the case, but it may cause more rows to
           be returned than you expected, though this depends on the query.

           NOTE: The adding of columns to the SELECT clause from the ORDER BY clause is
           considered experimental, because it can change the expected results in some cases.

       •   where (optional)

           See the documentation on where clauses for the Alzabo::Runtime::Table class.

       •   order_by (optional)

           See the documentation on order by clauses for the Alzabo::Runtime::Table class.

       •   limit (optional)

           See the documentation on limit clauses for the Alzabo::Runtime::Table class.

       If the "select" parameter specified that more than one table is desired, then this method
       will return n JoinCursor object representing the results of the join.  Otherwise, the
       method returns a RowCursor object.

       Throws: "Alzabo::Exception::Logic", "Alzabo::Exception::Params"

   one_row
       This method takes the exact same parameters as the "join()" method but instead of
       returning a cursor, it returns a single array of row objects.  These will be the rows
       representing the first row (a set of one or more table's primary keys) that is returned by
       the database.

       Throws: "Alzabo::Exception::Logic", "Alzabo::Exception::Params"

   function and select
       These two methods differ only in their return values.

       They both take the following parameters:

       •   select => $function or [ scalars, SQL functions and/or "Alzabo::Column" objects ]

           If you pass an array reference for this parameter, it may contain scalars, SQL
           functions, or column objects.  For example:

             $schema->function( select =>
                                [ 1,
                                  $foo->column('name'),
                                  LENGTH( $foo->column('name') ) ],
                                join => [ $foo, $bar_table ],
                              );

           This is equivalent to the following SQL:

             SELECT 1, foo.name, LENGTH( foo.name )
               FROM foo, bar
              WHERE ...

       •   join

           See the documentation on the join parameter for the join method.

       •   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.

       •   group_by

           See the documentation on group by clauses for the Alzabo::Runtime::Table class.

       •   having

           This parameter is specified in the same way as the "where" parameter, but is used to
           generate a "HAVING" clause.  It only allowed when you also specify a "group_by"
           parameter.

       •   limit

           See the documentation on limit clauses for the Alzabo::Runtime::Table class.

       These methods are used to call arbitrary SQL functions such as 'AVG' or 'MAX', and to
       select data from individual columns.  The function (or functions) should be the return
       values from the functions exported by the SQLMaker subclass that you are using.  Please
       see Using SQL functions for more details.

       Throws: "Alzabo::Exception::Logic", "Alzabo::Exception::Params"

       function() return values

       The return value of this method is highly context sensitive.

       If you only requested a single element in your "select" parameter, such as
       "DISTINCT(foo)", then it returns the first value in scalar context and all the values as
       an array in list context.

       If you requested multiple functions such as "AVG(foo), MAX(foo)", then it returns a single
       array reference, the first row of values, in scalar context and a list of array references
       in list context.

       select() return values

       This method always returns a new "Alzabo::DriverStatement" object containing the results
       of the query.  This object has an interface very similar to the Alzabo cursor interface,
       and has methods such as "next()", "next_as_hash()", etc.

   row_count
       This method is simply a shortcut to get the result of COUNT('*') for a join.  It
       equivalent to calling "function()" with a "select" parameter of "COUNT('*')".

       Throws: "Alzabo::Exception::Logic", "Alzabo::Exception::Params"

   prefetch_all
       This method will set all the tables in the schema to prefetch all their columns.  See the
       lazy column loading section in "Alzabo::Runtime::Table" for more details.

   prefetch_all_but_blobs
       This method will set all the tables in the schema to prefetch all their non-blob-type
       columns.

       This method is called as soon as a schema is loaded.

   prefetch_none
       This method turns of all prefetching.

   name
       Returns a string containing the name of the schema.

   tables (@optional_list)
       If no arguments are given, this method returns a list of all "Alzabo::Runtime::Table"
       objects in the schema, or in a scalar context the number of such tables.  If one or more
       arguments are given, returns a list of table objects with those names, in the same order
       given (or the number of such tables in a scalar context, but this isn't terribly useful).

       An "Alzabo::Exception::Params" exception is throws if the schema does not contain one or
       more of the specified tables.

   table ($name)
       Returns an "Alzabo::Runtime::Table" object representing the specified table.

       An "Alzabo::Exception::Params" exception is throws if the schema does not contain the
       table.

   has_table ($name)
       Returns a boolean value indicating whether the table exists in the schema.

   begin_work
       Starts a transaction.  Calls to this function may be nested and it will be handled
       properly.

   rollback
       Rollback a transaction.

   commit
       Finishes a transaction with a commit.  If you make multiple calls to "begin_work()", make
       sure to call this method the same number of times.

   run_in_transaction ( sub { code... } )
       This method takes a subroutine reference and wraps it in a transaction.

       It will preserve the context of the caller and returns whatever the wrapped code would
       have returned.

   driver
       Returns the "Alzabo::Driver" object for the schema.

   rules
       Returns the "Alzabo::RDBMSRules" object for the schema.

   sqlmaker
       Returns the "Alzabo::SQLMaker" object for the schema.

JOINING A TABLE MORE THAN ONCE

       It is possible to join to the same table more than once in a query.  Table objects contain
       an "alias()" method that, when called, returns an object that can be used in the same
       query as the original table object, but which will be treated as a separate table.  This
       faciliaties queries similar to the following SQL::

         SELECT ... FROM Foo AS F1, Foo as F2, Bar AS B ...

       The object returned from the table functions more or less exactly like a table object.
       When using this table to set where clause or order by (or any other) conditions, it is
       important that the column objects for these conditions be retrieved from the alias object.

       For example:

        my $foo_alias = $foo->alias;

        my $cursor = $schema->join( select => $foo,
                                    join   => [ $foo, $bar, $foo_alias ],
                                    where  => [ [ $bar->column('baz'), '=', 10 ],
                                                [ $foo_alias->column('quux'), '=', 100 ] ],
                                    order_by => $foo_alias->column('briz') );

       If we were to use the $foo object to retrieve the 'quux' and 'briz' columns then the join
       would simply not work as expected.

       It is also possible to use multiple aliases of the same table in a join, so that this will
       work properly:

        my $foo_alias1 = $foo->alias;
        my $foo_alias2 = $foo->alias;

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 environment, this is not a problem.  For example, 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.

       In addition, there are a number of modules aimed at helping store and use this sort of
       information on CPAN, including "DBIx::Connect" and "AppConfig", among others.

AUTHOR

       Dave Rolsky, <autarch@urth.org>