I'm evaluating liquibase for a project starting today.
Has anybody used it to create procedures, functions, basically all of the plsql stuff?
If not, is it possible to write embedded sql code in the xml files?
There is a built-in createProcedure tag in liquibase for managing procedures. The best approach is usually to combine the or tags with runOnChange so liquibase will update your procedure when and only when you update the definition. That way you can do diffs between your changelog xml files over time and see how the procedure has changed.
Using the sqlFile tag to reference file per stored-proc is also popular, or, like you said, you can use the sql tag to inline custom sql.
I've encountered issues with trying the use the sql tag for stored procedures, triggers, and functions, but in my case these were provably issues with the MySQL JDBC driver, and not Liquibase itself. The practice I've settled into is to use the sqlFile refactoring as Nathan suggests, then to control the SP/trigger/function code in the same project as the changelog, versioned in the source code system along with it. This lets you manage the SP/whatever code just like it was real source code.
Setting runOnChange="true" in the changeSet containing the sqlFile refactoring is essential. It is this switch (thank you, Nathan) that enables real source control of procedural database code.
While I haven't used liquibase for stored procedures, I have some experience of Liquibase for more generic operations.
It is possible to write custom sql, either embedded in the xml file or referenced from an external file.
Related
In my current liquibase project I usually use plain SQL to create tables, because I believe it gives better control over the DDL syntax, and I can paste exactly what I modeled. Of course I'm losing the automatic rollback functionality, but except that - are there any other benefits of using createTable elements over plain SQL?
I thought it has some advantages when you switch to a different database server, but even in this case I would probably just create a different version of the SQL manually (again, for better control over the DDL syntax).
I think that XML files are more clear to read, but does it have advantage over SQL format. I found some info [here] (http://forum.liquibase.org/topic/liquibase-sql-vs-xml-command-changesets), but I would nice to hear others voices.
I prefer using xml file because it's more abstract. For example you can define column type by VARCHAR/java.sql.Types.VARCHAR and liquibase will replace that by default configuration for target database - so it is not database specific. But if you have some database specifics (like plsql) then I'm using .sql files and loading them with sqlFile change.
One of the primary reasons that Datical chose Liquibase as the core of our product was that the XML gave us the ability to look at the changelog in a programmatic way, allowing us to do things like forecasting the changes that would be made before they are applied to a database, and the ability to write rules against the changelog. If used with care, XML can give you a database-independent way of managing db changes also.
I need to create a database in SQLite, but I do not want to create the tables manually.
I already have the model of the data I need in the database, and what kind of relationship is each one (many-many, one-many, ...)
I'm wondering if there is a tool that allows me to do that?
I just need the tool to generate the SQL code. Then I will take care of the queries manually using SQL
I was thinking about placing the model in Django, and see what it generates, but there should be a tool not linked to a particular language that allows me to do that. Am I wrong?
Hibernate have the ability to create a scheme from mapped classes. There is support for SQLite.
You can go for dia (see "Tools that generates something from Dia diagrams" at http://projects.gnome.org/dia/links.html).
Also there is SQL::Translator and DBIx::* that allows reading an schema from YAML, Excel, and other sources, but these are Perl specific.
Good luck
You can use Symfony + Doctrine framework. It can generate SQL queries.
Try this module on CPAN: Parse::Dia::SQL
Up until now, my experience with databases has always been working with an intermediate definition layer that we have where I work. i.e. SQL wasn't directly written for the table definitions, but generated from an intermediate file which wrote out SQL scripts for creating the appropriate tables, upgrade scripts between schema changes, and helper functions for doing simple queries/updates/inserts/deletes from the database.
Now I'm in a situation where I don't have access to that, for reasons I won't get into, and I find myself somewhat lost at sea regarding what to do. I need to have a small number of tables in a database, and I'm unsure what's usually done to manage the table definitions.
Do people normally just use the SQL script that does the table creation as their definition, or does everyone just use an IDE that manages the definition in a separate file and regenerates the SQL script to create the tables?
I'd really prefer not to have to introduce a dependence on a specific IDE, because as we all know, developers are whiners that are prone to religious debates over small things.
Open your favorite text editor -> Start writing CREATE scripts -> Save -> Put in Source Control
That script now becomes the basis for you database. Anytime there are schema changes, they get put back into the scripts so that they don't get lost.
These become your definition.
I find it more reliable than depending on any specific IDE/Platform generating those scripts for you.
We write the scripts ourselves and store them in source control like any other code. Then the scripts that are appropriate for a particular version are all groupd together and promoted to prod together. Make sure to use alter table when changing existing tables becasue you don't want to drop and recreate them if they have data! I use a drop and recireate for all other objects though. If you need to add records to a particular table (usually a lookup of sometype) we do that in scripts as well. Then that too gets promoted with the rest of the version code.
For me, putting the scripts in source control however they are generated is the key step. This is how you know what you have changed for the next release. This is how you can see earlier versions and revert back easily if there is a problem. Treat database code the same wayyou treat all other code.
YOu could use one of the data modelling tools that creates scripts for you if you are starting out on a database design and the eventually want to create it for you. Some tools for that are Erwin, Fabforce etc... (though not free)
If you have access to an IDE like SQL Management studio, you can create them by using an GUI thats pretty simple.
If you are writing your own code, Its always better to write your own scripts based on a good template so that you cover all the properties of the definition of the table like the file_group, Collation & stuff. Hope this helps
Once you do create a base copy generate scripts and have a base reference copy of it so that you could do "incremental" changes on them and manage them in a source control.
Though I use TOAD for Oracle, I always write the scripts to create my database objects by hand. It gives you (and your DBA's) more control and knowledge of what's being created and how.
If your schema is too difficult to describe in SQL, you probably have other issues more pressing than which IDE. Use modelling documentation if you need a graphical representation, but yeah, you don't need an IDE.
There are multiple ways out there for what you are asking.
Old traditional way is to have a script file ready with your application that has CREATE TABLE statement.
If you are a developer, and that too a Java enterprise developer, you could generate complete schema using a persistence library called Hibernate. Here is a how to
If you are a DBA level user, you could take schema export from one environment and import that in to your current environment. This is a standard practice among DBAs. But it requires admin access as you can see. Also, the methods are dependent on the database you are using (oracle, db2 etc)
This is a problem that I come to on occasion and have yet to work out an answer that I'm happy with. I'm looking for a build system that works well for building a database - that is running all of the SQL files in the correct database instance as the correct user and in the correct order, and handling dependencies and the like properly.
I have a system that I hacked together using Gnu Make and it works, but it's not especially flexable and frankly can be a bit of a pain to work with in some situations. I've considered looking at things like SCons and CMake too, but I don't know how much better they are likely to be, or if there's a better system out there that already exists...
Just a shell script that runs all the create statements and imports in the proper order. You may also find migrations (comes with rails) interesting. It provides a make like infrastructure that let's you maintain a database the structure of which evolves over time.
Say you add a new column to some table. In migrations you'd write a snippet of code which describes the requirements for adding the column and also to rollback the change so you can switch to different versions of your schema automatically.
I'm not a big fan of the tight integration with rails, though, but the principles behind it are very interesting.
For SQL Server, I just use a batch file with SQLCMD.EXE and a bunch of .SQL files. It's not perfect, but it seems to work.
For my database, I use Migrator.NET
This is a .NET framework which allows you to create classes in where you define your DDL statements.
The framework comes with a command-line tool with which you can execute your 'migrations' in the correct order.
It also has a msbuild - task, so you can integrate it in a continuous integration build as well.
First export full DDL files describing all tables, views, source code
(procedures, functions, packages), sequences, and grants of a DB schema
See
Is there a tool to generate a full database DDL for SQL Server? What about Postgres and MySQL?
I created a database build system (part SQL-parser, part make file) to put these files together in a DB creation script using python.