samskivert
52f5b41f44
initialValue=N) for non-zero values of N. This is complicated. Depot used to
"initialize" value generators pretty much every time a table schema was
migrated. For TableValueGenerator it could just NOOP if the proper row was in
the sequence table. IdentityValueGenerator was just broken and ignored any
request to configure an initialValue, so it never did anything.
First I looked into preserving this frequent reinitialization behavior, but it
turns out that it's not possible to read the current value of a sequence in
Postgres without modifying it. So trying to do something like:
SELECT setval('"FooRecord_fooId_seq"', max(currval('"FooRecord_fooId_seq"'),
cast(initialValue as bigint)));
doesn't work because you can't call currval() without first having called
nextval() (and furthermore when you do that, the Postgres client grabs a block
of sequence values for this client so that multiple clients can add rows to a
table without having to coordinate with the server and one another to assign a
new value every time a row is inserted).
So I changed Depot around to not reinitialize value generators unless it really
believes that the column in question is newly added. We can't rely on our own
auto-column creation because it's possible for someone to create a column
through a custom entity migration, so instead we just keep track of what
columns we had before we started all of our migrations (automatic and custom)
and check to see if there are any new columns after all is said and done and if
any of those have value generators, we "create" them.
This allows us to just setval() the sequence to the desired initial value
without first reading it.
This all fails if someone renames a column with a value generator. The column
will appear to Depot to be new and it will try to recreate the value generator
on that column. For TableValueGenerators that will basically NOOP and
everything will be just like it was before. For IdentityValueGenerators,
because of the way that Postgres magically creates a tablename_columnname_seq
sequence for identity value generation, when the column is renamed, the
sequence will retain the old column name and when Depot goes to try to setval()
the sequence based on the new column name, it won't exist and the migration
will fail. So at least we're not silently reinitializing the value generator to
its initial value when a column (with an identity value generator) is renamed.
We also don't try to do anything if the initialValue is not 1 (the default). So
we avoid failing or doing anything wrong if those kinds of columns are renamed.
So we only fail if someone renames a column with an identity value generator
with a non-default initial value. Since one can only put a value generator on a
primary key field and an identity value generator generally means you have
something simple like FooRecord with fooId. This means someone is renaming
their simple auto incrementing primary key field which seems extremely unlikely
because those columns usually have an obvious name that you're never going to
change. No problem!
I also haven't fixed this problem for MySQL yet. I can only handle so much
database befuckaroundery in one go.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2436 6335cc39-0255-0410-8fd6-9bcaacd3b74c
The samskivert library ---------------------- The samskivert library (SL) aims to provide useful reusable Java routines that do things for which I've been unable to find useful reusable implementations on the net. Given the emphasis on reusability, SL attempts to closely adhere to the following principles: * Each individual module should depend as little as possible on other SL modules. Obvious exceptions include modules that are a logical extension of other modules and modules that clearly require a service that is implemented by another SL module and would have to implement that service themselves in the absence of dependence on the other module. * Modules should be both simple to use and as general purpose as possible. To meet these two competing requirements, a balance must be struck at that sweet spot where reusability is maximized. * Code included in SL will freely depend on JDK packages available in the Java 2 platform and beyond. SL is initially a repository of software useful for server-side or stand alone applications and therefore need not make compromises to function in the jungle of JVMs in commonly available web browsers. * We are not here to reinvent the wheel, nor to provide a uniform interface to every software service under the sun. If something is available in a freely redistributable and reusable form from someone else, it won't be found in SL. If SL depends on such software from another source, it will provide clear documentation on how to get that software and make use of it within the scope of SL's particular needs. Again a balance of reusability will be struck here and software that is sufficiently difficult to make usable in an arbitrary environment will not be used by SL and may be "reinvented". Building -------- Building the library is very simple. First ensure that the necessary third party jar files are available either in the lib/ directory or in the system wide jar file location specified in build.xml. See lib/README for a list of the necessary third party jar files and how to get them. The library is built using ant, a modern build tool available from The Jakarta Project. If you aren't already using ant for other projects, it can be found here: http://jakarta.apache.org/ant/ Invoke ant with any of the following targets: all: builds the class files and javadoc documentation compile: builds only the class files (dist/classes) javadoc: builds only the javadoc documentation (dist/docs) dist: builds the distribution jar file (dist/samskivert.jar) Look at the build.xml file for configurable build parameters. Distribution ------------ The samskivert library is released under the LGPL. The most recent version of the library is available here: http://samskivert.com/code/samskivert/ Contribution ------------ Contributions to SL are welcome. Control of the CVS repository is presently in the hands of mdb@samskivert.com, who should be emailed about submissions. Facilities for management of major contributions by external parties (ie. publicly accessible CVS server) will be provided if circumstances dictate. Contact Information ------------------- The person primarily responsible for SL is Michael Bayne and can be contacted at <mdb@samskivert.com>. $Id: README,v 1.7 2001/08/12 00:00:42 mdb Exp $