If copying from a database without a global index namespace (e.g. MySQL) to a database with a global index namespace (e.g. PostgreSQL), the previous copying could break if you had indexes with the same name in both tables. To work around this, prepend the table name to the index name when copying. Note that if the index name exactly matches Sequel's default name, it will not do any additional namespacing.
…odels by loading cached schema information from a file This idea is taken from ActiveRecord, which will be adding the feature in 4.0. Basically, when loading a large number of models, there may be significant time spent loading the table schema for each table from the database, especially in high latency situations. To work around this, you can cheat by caching the information to a file, and then loading the cached file instead of querying the database for each table/model, which is what this extension does. To make it easy to generate the cached schema files, an -S option is being added to bin/sequel that creates the cached schema dump file. It's up to the application to use load_schema_cache to preload the schema cache.
Instead of trying to check all combintions, just add each exclusive option to an array, and error if more than one of the options is used.
This is mostly intended for use by the specs, but I've also changed bin/sequel to use it if no database was provided. Currently, Sequel uses a MockDatabase in the specs, but it has issues. It doesn't mock transactions or Sequel's sharding support correctly, and it doesn't provide any way to set the return values when using insert, update, or delete, or a way to set the rows returned by fetch_rows. Many of the specs that use it do their own mocking by defining methods, and can be changed to use this new mock adapter to simplify things.
…is not a tty Previously, unless the -m, -C, -d, or -D options was given, bin/sequel always gave an IRB prompt. This changes that behavior so that if any arguments are present, they are interpreted as filenames and are loaded. Also, if $stdin is not a tty, it is read from and evaled. These changes make bin/sequel operate more like a standard *nix program. For recent Linux users, this also means you can have a shebang line such as: #!/usr/bin/sequel postgres://user:pass@host/db to create a self contained script, where you can have ruby code in the script, with the DB constant already set. This is because recent Linux versions (since 2.6.28) support recursion in the #! handling.
Previously, -r files would be loaded before the DB constant was established. Now, it holds the information in the same data structure as the -L option, which enables it to be loaded in the same order. So if you specify -L before -r, the -L dir will be loaded before the -r dir is required, and vice versa.
…are used Previously, the -L option would not be loaded if one of the above options was used.
… connection The default setting of bin/sequel has been to test the connection before bringing up an IRB shell, but the previously Sequel had no way of doing this automatically (bin/sequel just called test_connection manually after instantiating the database object). This commit allows Sequel.connect and related methods to take a :test option that specifies whether a connection attempt should be made directly after connecting. Like other connection options, on adapters other than do and jdbc, you can specify the option in the connection string: Sequel.connect('postgres://host/database?test=t') It is possibly that this will be the default in a later version of Sequel, though I do not have plans to do that currently. While here, switch bin/sequel over to using this new capability.
…things without a real database
…ion is raised
…dumping in the database-specific type format When doing a database independent schema dump, include code to ignore errors when creating indexes. This should allow you to dump the schema from a PostgreSQL database with an index on a text column and restore it in a MySQL database. This modifies the bin/sequel tool to use the new feature when copying databases, and tweaks the output slightly.
This should work with any combination of database types, and one of the reasons for creating it is to make it easier to find bugs in the Sequel's schema support and the schema_dumper extension.
The -d option uses type translation, the -D option does not. The schema migration is dumped to the standard output. This should be helpful if you want an immediate look at the columns in the database. If you want to use it as the basis for an initial migration, just redirect $stdout to a file. While here, add a -h option to print the usage, since that is more standard than -?. Check for options that can't be used together, such as -D or -d with -m. Also check for options that require other options, such as -M without -m. Don't print the options when an error occurs, just print an error message. I initially thought of having -d/-D use -m to create a file in that directory, but there are a lot of corner cases there that I don't want to deal with.
I suppose this is useful if you want to load models from multiple directories. Seems like a fairly rare need, but the change is easy and makes usage more intuitive. Previously, if you used multiple -L options, only the last one would be respected, now, all -L options are respected.
…n' if you want them Migrations and the Migrator are not generally needed in normal operation. The only part of Sequel that depends on them is the sequel binary when called with the -m switch. So it is easy to move them into an extension. Since migrations are only run rarely, it doesn't make sense for Sequel to load the code for them by default.
…mbol keys This commit will try the following in order to find the parameters to use: # Assume yaml_hash is the hash returned by YAML.load for the # file given on the command line, and env is the environment # specified by the user (or 'development' by default) params = yaml_hash[env] || yaml_hash[env.to_sym] || yaml_hash Notice that in addition to supporting symbol keys (such as :development), Sequel now also supports a plain yaml file for parameters, such as: --- :adapter: sqlite :database: ':memory:'
…ads all Sequel::Models
For merging the READMEs, I put the model README at the bottom of the core README and used that. For merging the CHANGELOGs, I merged them manually back to 1.4.0, and copied the rest of the model CHANGELOG to the bottom of the file. Most of the Rakefile code was duplicative, but I think I got all tasks except spec_adapters. I figure few people have all 5 adapters necessary to run the adapter specs. I only have 3 of them, so I never used spec_adapters. The specs are still split up so they can be run independently. Additionally, the adapter specs are split off from the core specs, which helps if you want to put Sequel.connect lines in spec_config.rb. The only other spec changes were for path changes. There weren't conflicts merging anything else, IIRC. I hope there is no fallout from this. I haven't noticed any yet, running the specs and the test suites for all of my apps that use Sequel.
…amed Pool#conn_maker to Pool#connection_proc. Added Dataset# method. Refactored Model#find and Model#.