view release on metacpan or  search on metacpan

lib/Alzabo/Index.pm  view on Meta::CPAN

=head1 METHODS

=head2 columns

Returns an ordered list of the L<C<Alzabo::Column>|Alzabo::Column>
objects that are being indexed.

=head2 prefix (C<Alzabo::Column> object)

A column prefix is, to the best of my knowledge, a MySQL specific
concept, and as such cannot be set when using an RDBMSRules module for
a different RDBMS.  However, it is important enough for MySQL to have
the functionality be present.  It allows you to specify that the index
should only look at a certain portion of a field (the first N
characters).  This prefix is required to index any sort of BLOB column
in MySQL.

This method returns the prefix for the column in the index.  If there
is no prefix for this column in the index, then it returns undef.

lib/Alzabo/Intro.pod  view on Meta::CPAN

L<C<Alzabo::Runtime::Row> documentation|Alzabo::Runtime::Row/POTENTIAL
ROWS> for details on how these objects can be created.

=head2 Changing the schema

In MySQL, there are a number of various types of integers.  The type
C<TINYINT> can hold values from -128 to 127.  But what if have more
than 127 movies?  And if that's the case we might have more than 127
people too.

For safety's sake, it might be best to make all of the primary key
integer columns C<INT> columns instead.  And while we're at it we want
to make them C<UNSIGNED> as well, as we don't need to insert negative
numbers into these columns.

You could break out the RDBMS manual (because you probably forgot the
exact C<ALTER TABLE> syntax you'll need).  Or you could use Alzabo.
Note that this time we use a
L<C<Alzabo::Create::Schema>|Alzabo::Create::Schema> object, not
L<C<Alzabo::Runtime::Schema>|Alzabo::Runtime::Schema>.

lib/Alzabo/Runtime/Schema.pm  view on Meta::CPAN

L<C<set_user()>|Alzabo::Runtime::Schema/set_user ($user)> and
L<C<set_password()>|Alzabo::Runtime::Schema/set_password ($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 C<DBIx::Connect> and
C<AppConfig>, among others.

=head1 AUTHOR

Dave Rolsky, <autarch@urth.org>