I agree that the auto-increment is a common enough case we should support it, and I have enough unix background to appreciate having enough rope...
I'll add it as an issue to the tracker so it is implemented, hopefully with 1.7.
Nathan
________________________________
From: liquibase-user-***@lists.sourceforge.net on behalf of Dave White
Sent: Mon 3/31/2008 10:23 AM
To: liquibase-***@lists.sourceforge.net
Subject: Re: [Liquibase-user] Ignoring autoIncrement column attributefordatabases that don't support it?
That all makes sense and I do see it from your point of view of making sure no "false promises" are made. I would be happy with a flag that I could set somewhere to indicate that unsupported features should be ignored when generating the SQL (this autoIncrement being the only example I can think of now but I'm sure there could be other cases). In this way, as a user of Liquibase, I can explicitly request the rope from which I could hang myself.
FWIW - I think this may be a fairly common case for users coming from Hibernate that have setup an 'id' column with a generator like this:
Hibernate HBM XML
------------------------------------------
<id name="id" column="ID" unsaved-value="-1">
<generator class="native"/>
</id>
Hibernate Annotations:
------------------------------------------
@Id @GeneratedValue(strategy = GenerationType.AUTO)
public int getId() ...
The 'native' generator will use either a sequence, identity column or hilo algorithm depending on the underlying DB support. The Hibernate docs do sort of recommend the 'native' approach for "cross platform" DB development. I suppose this would also affect the new Hibernate support as it may be tricky to know how to create the 'ID' column in the changelog if it was mapped with a 'native' generator.
Dave
--
On Mon, Mar 31, 2008 at 10:28 AM, Voxland, Nathan <***@intelligentinsites.com> wrote:
You are right that the dbms="xxx" tag is the way to work around incompatible differences between databases.
The question on what to do with incompatible differences is something I have thought about it the past. The main reason I went with the "fail on unsupported" method was because I was afraid of situations like this: A changelog is created for one database type (say mysql) which supports auto Increment but then it begins to be used on Oracle and everything appears to be build correctly because the autoIncrement="true" attributes are silently ignored. The code, however, assumes that the columns are auto increment and fails at some unknown point down the road in a less obvious and more troubling way.
So the current functionally is designed to make you deal with database differences up front rather than making you think that your update worked as specified but it actually didn't.
That being said, you are right that duplicating everything does get to be a pain and it would help to have some sort of "ignore auto increment if unsupported" flag could be passed. I'm not sure if autoIncrement is a special case where that makes sense and should be treated specially or if there should be a general "ignore unsupported operations" flag.
Nathan
From: liquibase-user-***@lists.sourceforge.net [mailto:liquibase-user-***@lists.sourceforge.net] On Behalf Of Dave White
Sent: Monday, March 31, 2008 8:20 AM
To: liquibase-***@lists.sourceforge.net
Subject: [Liquibase-user] Ignoring autoIncrement column attribute fordatabases that don't support it?
I have a changelog that I'd like to support on a number of databases, one of which is Oracle. In the changelog all the <createTable> statements have a primary key <column> with autoIncrement="true". This works great for databases that support it, but when I run it on Oracle it fails with a syntax error as it is putting the 'autoincrement' statement in the create table SQL statement. Now I think I can create separate changesets for the different database types using the dbms="xxx" attribute, but this seems like a maintenance headache (i.e. everything in the <createTable> would be the same in the different changesets, except the autoIncrement would need to be omitted for Oracle). Would it make sense to simply ignore an attribute like autoIncrement on a column if the database doesn't support it? Any clues on the right way to to this would be great.
Thanks,
Dave
--
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Liquibase-user mailing list
Liquibase-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/liquibase-user