The following example shows simplistically how you might use DBIx::Class to
deploy versioned schemas to your customers. The basic process is as follows:
-1) Create a DBIx::Class schema
-2) Save the schema
-3) Deploy to customers
-4) Modify schema to change functionality
-5) Deploy update to customers
+=over 4
+
+=item 1.
+
+Create a DBIx::Class schema
+
+=item 2.
+
+Save the schema
+
+=item 3.
+
+Deploy to customers
+
+=item 4.
+
+Modify schema to change functionality
+
+=item 5.
+
+Deploy update to customers
+
+=back
=head3 Create a DBIx::Class schema
There are several ways you could deploy your schema. These are probably
beyond the scope of this recipe, but might include:
-1) Require customer to apply manually using their RDBMS.
-2) Package along with your app, making database dump/schema update/tests
+=over 4
+
+=item 1.
+
+Require customer to apply manually using their RDBMS.
+
+=item 2.
+
+Package along with your app, making database dump/schema update/tests
all part of your install.
+=back
+
=head3 Modify the schema to change functionality
As your application evolves, it may be necessary to modify your schema to
The schema update can be deployed to customers using the same method as before.
+=head2 Setting limit dialect for SQL::Abstract::Limit
+
+In some cases, SQL::Abstract::Limit cannot determine the dialect of the remote
+SQL-server by looking at the database-handle. This is a common problem when
+using the DBD::JDBC, since the DBD-driver only know that in has a Java-driver
+available, not which JDBC-driver the Java component has loaded.
+This specifically sets the limit_dialect to Microsoft SQL-server (Se more names
+in SQL::Abstract::Limit -documentation.
+
+ __PACKAGE__->storage->sql_maker->limit_dialect('mssql');
+
+The JDBC-bridge is one way of getting access to a MSSQL-server from a platform
+that Microsoft doesn't deliver native client libraries for. (e.g. Linux)
+
=cut