view release on metacpan or  search on metacpan

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

Alzabo to be incompatible with a saved schema.

As of Alzabo version 0.65, Alzabo can now detect older schemas and
will attempt to update them if possible.

When you attempt to load a schema, whether of the
C<Alzabo::Create::Schema> or C<Alzabo::Runtime::Schema> classes,
Alzabo will determine what version of Alzabo created that schema.

If updates are necessary, Alzabo will first back up your existing
files with the extension F<.bak.v{version}>, where "{version}" is the
version of Alzabo which created the schema.

Then it will alter the schema as necessary and save it to disk.

This will all happen transparently, as long as the process which
initiated this process can write to the schema files and the directory
they are in.

Alzabo will need the C<Alzabo::Create::*> classes to update the
schema.  If these have not been loaded already, Alzabo will do so and
issue a warning to say that this has happened, in case you would like
to restart the process without these classes loaded.

=head1 MULTIPLE COPIES OF THE SAME SCHEMA

It is possible to use the same schema definition with multiple copies
of that schema in the RDBMS.  This can be done by setting the
"schema_name" parameter whenever you call a method that connects to
the RDBMS, such as L<<
C<Alzabo::Create::Schema-E<gt>create>|Alzabo::Create::Schema/create >>
or L<<
C<Alzabo::Runtime::Schema-E<gt>connect>|Alzabo::Runtime::Schema/connect
>>.  This will override the default, the schema's name as given when
it was first created via L<<
C<Alzabo::Create::Schema-E<gt>new>|Alzabo::Create::Schema/new >>.

Every time you call C<create()> or C<sync_backend()>, the schema will
consider itself to have been instantiated.  This means that if you
call C<create()> twice, each time with a different "schema_name"
parameter, then you will probably not be able to generate useful diffs
via the C<make_sql()> method in the future.

This is a bug that is unlikely to be fixed.

=head1 MULTIPLE RDBMS SUPPORT

Alzabo aims to be as cross-platform as possible.  To that end, RDBMS
specific operations are contained in several module hierarchies.  The
goal here is to isolate RDBMS-specific behavior and try to provide
generic wrappers around it, inasmuch as is possible.

The first, the C<Alzabo::Driver::*> hierarchy, is used to handle
communication with the database.  It uses C<DBI> and the appropriate
C<DBD::*> module to handle communications.  It provides a higher level
of abstraction than C<DBI>, requiring that the RDBMS specific modules
implement methods to do such things as create databases or return the
next value in a sequence.

The second, the C<Alzabo::RDBMSRules::*> hierarchy, is used during
schema creation in order to validate user input such as schema and
table names.  It also generates DDL SQL to create the database or turn one
schema into another (sort of a SQL diff).  Finally, it also handles
reverse engineering of an existing database.

The C<Alzabo::SQLMaker::*> hierarchy is used to generate DML SQL and
handle bound parameters.

The RDBMS to be used is specified when creating the schema.
Currently, there is no easy way to convert a schema from one RDBMS to
another, though this is a future goal.

=head1 REFERENTIAL INTEGRITY

Alzabo can maintain referential integrity in your database based on
the relationships you have defined.  This can be toggled via L<< the
C<Alzabo::Runtime::Schema-E<gt>set_referential_integrity()>
method|Alzabo::Runtime::Schema/set_referential_integrity >>.

Alzabo enforces these referential integrity rules:

=over 4

=item * Inserts

An attempt to insert a value into a table's foreign key column(s) will
fail if the value does not exist in the foreign table.

If a table is dependent on another table, any columns from the
dependent table involved in the relationship will be treated as not
nullable.

If the relationship is one-to-one, all columns involved in the foreign
key will be treated as if they had a unique constraint on them (as a
group if there is more than one) unless any of the columns being
inserted are NULL.

The exception to this rule is that no attempt is made to enforce
constraints on a table's primary key, as that could conceivably make
it impossible to insert a row into the table.

=item * Updates

Updates follow the same rules as inserts.

=item * Deletes

When a row is deleted, foreign tables which are dependent on the one
being deleted will have the relevant rows deleted.  Otherwise, the
foreign table's related column(s) will simply be set to NULL.

=back

=head1 AUTHOR

Dave Rolsky, <autarch@urth.org>

=cut