Free schema software for linux

Schema-compare is a script that will compares two database schema and show the differences side-by-side.
Schema-compare can also generate SQL statements that will alter the old database to match the schema of the new database.
The comparisons are correct, but the SQL statements at the bottom are not quite right, they are close to what is necessary, but probably not exactly right.
To install simply ungzip/untar the file wherever you want to put it in your web folder and then edit the include/config.inc.php file with the information needed to connect to the two databases you want to compare. Both databases need to be on the same database server and use the same username and password to connect to them.
Enhancements:
- This is the first release of schema-compare. It compares the database schema just fine, but the sql alter statements it creates could use some work.

SchemaCrawler project is a command-line tool to output your database schema and data in a readable form.
The output is designed to be diff-ed with previous versions of your database schema. SchemaCrawler is also an API that improves on the standard JDBC metadata.
Enhancements:
- SchemaCrawler now comes with bundled downloads for Microsoft SQL Server and MySQL.

XML::Validator::Schema is a Perl module to validate XML against a subset of W3C XML Schema.

SYNOPSIS

use XML::SAX::ParserFactory;
use XML::Validator::Schema;

#
# create a new validator object, using foo.xsd
#
$validator = XML::Validator::Schema->new(file => foo.xsd);

#
# create a SAX parser and assign the validator as a Handler
#
$parser = XML::SAX::ParserFactory->parser(Handler => $validator);

#
# validate foo.xml against foo.xsd
#
eval { $parser->parse_uri(foo.xml) };
die "File failed validation: $@" if $@;

This module allows you to validate XML documents against a W3C XML Schema. This module does not implement the full W3C XML Schema recommendation (http://www.w3.org/XML/Schema), but a useful subset. See the SCHEMA SUPPORT section below.

IMPORTANT NOTE: To get line and column numbers in the error messages generated by this module you must install XML::Filter::ExceptionLocator and use XML::SAX::ExpatXS as your SAX parser. This module is much more useful if you can tell where your errors are, so using these modules is highly recommeded!

DTD to XML Schema translator allows you to translate a Document Type Definition (DTD) into an XML Schema.

DTD to XML Schema translator lets you translate a Document Type Definition into an XML Schema (REC-xmlschema-1-20010502).

The translator can map meaningful DTD entities onto XML Schema constructs (simpleType, attributeGroup, group); the XML document model is not anonymized.

In addition, the translator can map DTD comments onto XML Schema documentation nodes in various ways.

Free available as Java class, Standalone application and as Web tool.

XML::Compile::Schema::XmlReader Perl module contains bricks to translate XML to HASH.

SYNOPSIS

my $schema = XML::Compile::Schema- >new(...);
my $code = $schema- >compile(READER = > ...);

The translator understands schemas, but does not encode that into actions. This module implements those actions to translate from XML into a (nested) Perl HASH structure.

DETAILS

Processing Wildcards

If you want to collect information from the XML structure, which is permitted by any and anyAttribute specifications in the schema, you have to implement that yourself. The problem is XML::Compile has less knowledge than you about the possible data.

anyAttribute

By default, the anyAttribute specification is ignored. When TAKE_ALL is given, all attributes which are fulfilling the name-space requirement added to the returned data-structure. As key, the absolute element name will be used, with as value the related unparsed XML element.

In the current implementation, if an explicit attribute is also covered by the name-spaces permitted by the anyAttribute definition, then it will also appear in that list (and hence the handler will be called as well).

Use XML::Compile::Schema::compile(anyAttribute) to write your own handler, to influence the behavior. The handler will be called for each attribute, and you must return list of pairs of derived information. When the returned is empty, the attribute data is lost. The value may be a complex structure.

Example: anyAttribute in XmlReader

Say your schema looks like this:

< schema targetNamespace="http://mine"
xmlns:me="http://mine" ... >
< element name="el" >
< complexType >
< attribute name="a" type="xs:int" / >
< anyAttribute namespace="##targetNamespace"
processContents="lax" >
< / complexType >
< / element >
< simpleType name="non-empty" >
< restriction base="xs:NCName" / >
< / simpleType >
< / schema >

Then, in an application, you write:

my $r = $schema- >compile(READER = > {http://mine}el
, anyAttribute = > ALL
);

my $h = $r- >( < < __XML );
< el xmlns:me="http://mine" >
< a >42< /a >
< b type="me:non-empty" >
everything
< / b >
< / el >
__XML

use Data::Dumper Dumper;
print Dumper $h;
__XML__
The output is something like
$VAR1 =
{ a = > 42
, {http://mine}a = > ... # XML::LibXML::Node with < a >42< /a >
, {http://mine}b = > ... # XML::LibXML::Node with < b >everything< /b >
};

You can improve the reader with a callback. When you know that the extra attribute is always of type non-empty, then you can do

my $read = $schema- >compile
( READER = > {http://mine}el
, anyAttribute = > &filter
);

my $anyAttRead = $schema- >compile
( READER = > {http://mine}non-empty
);

sub filter($$$$)
{ my ($fqn, $xml, $path, $translator) = @_;
return () if $fqn ne {http://mine}b;
(b = > $anyAttRead- >($xml));
}

my $h = $r- >( see above );
print Dumper $h;
Which will result in
$VAR1 =
{ a = > 42
, b = > everything
};

The filter will be called twice, but return nothing in the first case. You can implement any kind of complex processing in the filter.

Jifty::DBI::SchemaGenerator is a Perl module to generate table schemas from Jifty::DBI records.

This module turns a Jifty::Record object into an SQL schema for your chosen database. At the moment, your choices are MySQL, SQLite, or PostgreSQL. Oracle might also work right, though its untested.

SYNOPSIS

The Short Answer

See below for where we get the $handle and $model variables.

use Jifty::DBI::SchemaGenerator;
...
my $s_gen = Jifty::DBI::SchemaGenerator->new( $handle );
$s_gen->add_model($model);

my @statements = $s_gen->create_table_sql_statements;
print join("n", @statements, );
...
The Long Version
See Jifty::DBI for details about the first two parts.
MyModel
package MyModel;
# lib/MyModel.pm

use warnings;
use strict;

use base qw(Jifty::DBI::Record);
# your custom code goes here.
1;
MyModel::Schema
package MyModel::Schema;
# lib/MyModel/Schema.pm

use warnings;
use strict;

use Jifty::DBI::Schema;

column foo => type is text;
column bar => type is text;

1;
myscript.pl
#!/usr/bin/env perl
# myscript.pl

use strict;
use warnings;

use Jifty::DBI::SchemaGenerator;

use Jifty::DBI::Handle;
use MyModel;
use MyModel::Schema;

my $handle = Jifty::DBI::Handle->new();
$handle->connect(
driver => SQLite,
database => testdb,
);

my $model = MyModel->new($handle);
my $s_gen = Jifty::DBI::SchemaGenerator->new( $handle );
$s_gen->add_model($model);

# heres the basic point of this module:
my @statements = $s_gen->create_table_sql_statements;
print join("n", @statements, );

# this part is directly from Jifty::Script::Schema::create_all_tables()
$handle->begin_transaction;
for my $statement (@statements) {
my $ret = $handle->simple_query($statement);
$ret or die "error creating a table: " . $ret->error_message;
}
$handle->commit;

DBIx::Class::Schema::Loader::RelBuilder is a Perl module that builds relationships for DBIx::Class::Schema::Loader.

This class builds relationships for DBIx::Class::Schema::Loader. This is module is not (yet) for external use.

METHODS

new

Arguments: schema_class (scalar), fk_info (hashref), inflect_plural, inflect_singular

$schema_class should be a schema class name, where the source classes have already been set up and registered. Column info, primary key, and unique constraints will be drawn from this schema for all of the existing source monikers.

The fk_info hashrefs contents should take the form:

{
TableMoniker => [
{
local_columns => [ col2, col3 ],
remote_columns => [ col5, col7 ],
remote_moniker => AnotherTableMoniker,
},
# ...
],
AnotherTableMoniker => [
# ...
],
# ...
}

Options inflect_plural and inflect_singular are optional, and are better documented in DBIx::Class::Schema::Loader::Base.

generate_code

This method will return the generated relationships as a hashref per table moniker, containing an arrayref of code strings which can be "eval"-ed in the context of the source class, like:

{
Some::Source::Class => [
"belongs_to( col1 => AnotherTableMoniker )",
"has_many( anothers => AnotherTableMoniker, col15 )",
],
Another::Source::Class => [
# ...
],
# ...
}

You might want to use this in building an on-disk source class file, by adding each string to the appropriate source class file, prefixed by __PACKAGE__->.