Ruby 1.9.3/Rails 3.2 version now master, also tagged as bibapp-2.0.0
112 views
Skip to first unread message
hading2
Apr 2, 2013, 10:58:03 AM4/2/13
to bib...@googlegroups.com
Hi,
This is crossposted to the dev list.
As promised (or threatened, as you like), I've merged the Ruby 1.9.3/Rails 3.2 code and it is now master. Since it requires a change of ruby version to use I've also bumped the version number up to 2.0.0, even though there isn't really any major new functionality.
So to use master or 2.0.0 or later you'll need to switch from ree to 1.9.3 for your ruby. There is an included .rvmrc for users of rvm.
I also pushed the missing 1.2.2 (which I found) and 1.2.3 as the latest version using ree. For the most part I expect I'll be working off of the new version, so it's unlikely that very much more will happen here unless it's either really important or easy to backport. Not a lot is going on right now with the code anyway, so hopefully that won't prove to be too much of a problem.
I plan to update the documentation on github presently.
Howard
Mackenzie Brooks
Apr 4, 2013, 3:40:36 PM4/4/13
to bib...@googlegroups.com
Hi all,
So I made the switch to the new release, but I'm encountering errors when running rake db:migrate (per update instructions on Github). The original rake aborted message:
Please switch to Ruby 1.9's standard CSV library. It's FasterCSV plus support for Ruby's 1.9's m17n encoding engine.
I traced this to the remove_login_from_users.rb (11:in 'up') file. Google said to just remove FasterCSV, which I did, but then I received the "uninitialized constant RemoveLoginFromUsers::CSV" error. The note in the file indicated that it was not terribly vital, so I deleted it, just to see what my next error would be:
== FixPublishersRomeoColors: migrating =======================================
rake aborted!
An error has occurred, all later migrations canceled:
undefined method `sort_name=' for #<Publisher:0x007fcf17b38768>/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activemodel-3.2.13/lib/active_model/attribute_methods.rb:407:in `method_missing'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/attribute_methods.rb:149:in `method_missing'
/Users/Administrator/Documents/Projects/Connect/BibApp/lib/stop_word_name_sorter.rb:23:in `update_sort_name'
So what am I doing wrong?
Thanks!
Mackenzie
Howard Ding
Apr 4, 2013, 3:41:59 PM4/4/13
to bib...@googlegroups.com
I don't know, but I'll see if I can
figure it out.
Howard
Howard
--
You received this message because you are subscribed to the Google Groups "bibapp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+un...@googlegroups.com.
To post to this group, send email to bib...@googlegroups.com.
Visit this group at http://groups.google.com/group/bibapp?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
muz...@mskcc.org
Apr 4, 2013, 3:57:48 PM4/4/13
to bib...@googlegroups.com
You might try modifying the remove_login_from_users.rb file
And adding
require 'csv'
And then replace FasterCSV.open with just CSV.open
--
Programmer Analyst, Virtual Library Services
MSK Research Library
Memorial Sloan-Kettering Cancer Center
Howard Ding
Apr 4, 2013, 4:29:02 PM4/4/13
to bib...@googlegroups.com
On 4/4/2013 2:40 PM, Mackenzie Brooks
wrote:
Hi all,
So I made the switch to the new release, but I'm encountering errors when running rake db:migrate (per update instructions on Github). The original rake aborted message:
Please switch to Ruby 1.9's standard CSV library. It's FasterCSV plus support for Ruby's 1.9's m17n encoding engine.
I traced this to the remove_login_from_users.rb (11:in 'up') file. Google said to just remove FasterCSV, which I did, but then I received the "uninitialized constant RemoveLoginFromUsers::CSV" error. The note in the file indicated that it was not terribly vital, so I deleted it, just to see what my next error would be:
I'm not too concerned about this one. I replaced FasterCSV with CSV
in that file and it should be fine now (pushed to master).
== FixPublishersRomeoColors: migrating =======================================
rake aborted!
An error has occurred, all later migrations canceled:
undefined method `sort_name=' for #<Publisher:0x007fcf17b38768>/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activemodel-3.2.13/lib/active_model/attribute_methods.rb:407:in `method_missing'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/attribute_methods.rb:149:in `method_missing'
/Users/Administrator/Documents/Projects/Connect/BibApp/lib/stop_word_name_sorter.rb:23:in `update_sort_name'
So what am I doing wrong?
Probably nothing. I think this is an example of a problem that can
happen with Rails migrations. To wit, what this migration does is to
make sure that the Romeo color for a publisher isn't left blank (as
it could have been at the time when this code was written, which I
was trying to correct), and if it is it updates it and saves it.
However, this fires after_save callbacks on the Publisher, and one
of those involves the sort_name attribute, which isn't added until a
later migration. Rails migrations can be dangerous in this way if
they do this sort of thing.
I think I can fix this particular migration so that it bypasses the callbacks (which should be fine for what it does). I'll make that change and push it to master and then post another note here and you can try again.
I will note that I am seeing some other problems trying to install from scratch that I hadn't noticed and I'll take a look at those as well.
Howard
I think I can fix this particular migration so that it bypasses the callbacks (which should be fine for what it does). I'll make that change and push it to master and then post another note here and you can try again.
I will note that I am seeing some other problems trying to install from scratch that I hadn't noticed and I'll take a look at those as well.
Howard
Howard Ding
Apr 4, 2013, 4:33:06 PM4/4/13
to bib...@googlegroups.com
Okay, I've pushed the change to that
migration to master - if you'd like to pull the latest master from
github and give it another go let me know how that works.
Unfortunately I tend not to notice this type of migration problem. Because I'm actually writing most of the software at this point they tend to be applied to our installation immediately, and hence in the context of code where I know they'll work. So when code changes later I rarely notice myself that it may have broken a migration.
Thanks,
Howard
Unfortunately I tend not to notice this type of migration problem. Because I'm actually writing most of the software at this point they tend to be applied to our installation immediately, and hence in the context of code where I know they'll work. So when code changes later I rarely notice myself that it may have broken a migration.
Thanks,
Howard
On 4/4/2013 2:40 PM, Mackenzie Brooks wrote:
--
Howard Ding
Apr 4, 2013, 5:07:43 PM4/4/13
to bib...@googlegroups.com
Looking through the rest of the
migrations I don't think you'll have problems with any of them,
though there is a small chance with a couple of them.
Do let me know if you get through them all with the latest changes to master - if so then I'll tag the current changes as 2.0.1.
Do let me know if you get through them all with the latest changes to master - if so then I'll tag the current changes as 2.0.1.
Thanks,
Howard
On 4/4/2013 2:40 PM, Mackenzie Brooks wrote:
--
Mackenzie Brooks
Apr 4, 2013, 5:19:47 PM4/4/13
to bib...@googlegroups.com
Thanks Howard! I'll give this a shot a little later tonight when I can get off the reference desk.
Mackenzie Brooks
Apr 5, 2013, 12:21:19 PM4/5/13
to bib...@googlegroups.com
So I was able to get through a handful of migrations before encountering this:
rake aborted!An error has occurred, all later migrations canceled:
undefined method `sort_name=' for #<JournalArticle:0x007fe8f3cacf68>/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activemodel-3.2.13/lib/active_model/attribute_methods.rb:407:in `method_missing'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/attribute_methods.rb:149:in `method_missing'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/authorization-1.0.12/lib/publishare/identity.rb:111:in `method_missing'/Users/Administrator/Documents/Projects/Connect/BibApp/lib/stop_word_name_sorter.rb:23:in `update_sort_name'/Users/Administrator/Documents/Projects/Connect/BibApp/app/models/work.rb:149:in `before_save_actions'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activesupport-3.2.13/lib/active_support/callbacks.rb:451:in `_run__646292450448923014__save__1025488930084348983__callbacks'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activesupport-3.2.13/lib/active_support/callbacks.rb:405:in `__run_callback'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activesupport-3.2.13/lib/active_support/callbacks.rb:385:in `_run_save_callbacks'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activesupport-3.2.13/lib/active_support/callbacks.rb:81:in `run_callbacks'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/callbacks.rb:264:in `create_or_update'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/persistence.rb:84:in `save'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/validations.rb:50:in `save'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/attribute_methods/dirty.rb:22:in `save'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/transactions.rb:259:in `block (2 levels) in save'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/transactions.rb:313:in `block in with_transaction_returning_status'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/transactions.rb:208:in `transaction'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/transactions.rb:311:in `with_transaction_returning_status'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/transactions.rb:259:in `block in save'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/transactions.rb:270:in `rollback_active_record_state!'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/transactions.rb:258:in `save'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/persistence.rb:181:in `update_attribute'/Users/Administrator/Documents/Projects/Connect/BibApp/db/migrate/20111111201022_split_publication_date_in_works.rb:23:in `block in up'/Users/Administrator/Documents/Projects/Connect/BibApp/db/migrate/20111111201022_split_publication_date_in_works.rb:17:in `each'/Users/Administrator/Documents/Projects/Connect/BibApp/db/migrate/20111111201022_split_publication_date_in_works.rb:17:in `up'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:370:in `up'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:410:in `block (2 levels) in migrate'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:410:in `block in migrate'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/connection_adapters/abstract/connection_pool.rb:129:in `with_connection'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:389:in `migrate'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:528:in `migrate'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:720:in `block (2 levels) in migrate'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:777:in `call'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:777:in `ddl_transaction'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:719:in `block in migrate'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:700:in `each'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:700:in `migrate'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:570:in `up'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:551:in `migrate'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/railties/databases.rake:193:in `block (2 levels) in <top (required)>'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/task.rb:246:in `call'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/task.rb:246:in `block in execute'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/task.rb:241:in `each'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/task.rb:241:in `execute'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/task.rb:184:in `block in invoke_with_call_chain'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/task.rb:177:in `invoke_with_call_chain'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/task.rb:170:in `invoke'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/application.rb:143:in `invoke_task'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/application.rb:101:in `block (2 levels) in top_level'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/application.rb:101:in `each'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/application.rb:101:in `block in top_level'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/application.rb:110:in `run_with_threads'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/application.rb:95:in `top_level'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/application.rb:73:in `block in run'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/application.rb:160:in `standard_exception_handling'/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/rake-10.0.4/lib/rake/application.rb:70:in `run'
Howard Ding
Apr 5, 2013, 12:23:07 PM4/5/13
to bib...@googlegroups.com
Hi,
Okay, I should be able to fix that as well. I'll post back when I have it.
Howard
Okay, I should be able to fix that as well. I'll post back when I have it.
Howard
Howard Ding
Apr 5, 2013, 12:29:15 PM4/5/13
to bib...@googlegroups.com
I've pushed a fix to master.
Howard
On 4/5/2013 11:21 AM, Mackenzie Brooks wrote:
Mackenzie Brooks
Apr 5, 2013, 12:43:27 PM4/5/13
to bib...@googlegroups.com
Pulled that fix, but am getting a slightly different message. Let me know if this is an issue on my end.
== SplitPublicationDateInWorks: migrating ====================================
-- add_column(:works, :publication_date_year, :integer)
rake aborted!
An error has occurred, all later migrations canceled:
Mysql2::Error: Duplicate column name 'publication_date_year': ALTER TABLE `works` ADD `publication_date_year` int(11)/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:245:in `query'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:245:in `block in execute'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/connection_adapters/abstract_adapter.rb:280:in `block in log'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activesupport-3.2.13/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/connection_adapters/abstract_adapter.rb:275:in `log'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:245:in `execute'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/connection_adapters/mysql2_adapter.rb:211:in `execute'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:461:in `add_column'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:466:in `block in method_missing'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:438:in `block in say_with_time'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:438:in `say_with_time'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:458:in `method_missing'
/usr/local/rvm/gems/ruby-1.9.3-p194@bibapp/gems/activerecord-3.2.13/lib/active_record/migration.rb:334:in `method_missing'
/Users/Administrator/Documents/Projects/Connect/BibApp/db/migrate/20111111201022_split_publication_date_in_works.rb:3:in `up'
Howard Ding
Apr 5, 2013, 12:49:43 PM4/5/13
to bib...@googlegroups.com
Yes, this does look like a problem with your particular installation,
although I'm not sure how it might have come about. This migration is
trying change a single date column into three (one each for year, month,
and day) so that dates of just a year or year and month can be
supported. The error indicates that a column it is trying to add already
exists, which shouldn't be. The first time you tried to run the
migration it got past this point and then had an error later, but it
should have rolled back and removed the column.
How much do you know about Mysql? If you know enough to get the schema
of that table (or the whole database) I can perhaps diagnose from that.
If you don't I can figure out how to get it, but I haven't used mysql in
quite some time so I don't know offhand.
Howard
although I'm not sure how it might have come about. This migration is
trying change a single date column into three (one each for year, month,
and day) so that dates of just a year or year and month can be
supported. The error indicates that a column it is trying to add already
exists, which shouldn't be. The first time you tried to run the
migration it got past this point and then had an error later, but it
should have rolled back and removed the column.
How much do you know about Mysql? If you know enough to get the schema
of that table (or the whole database) I can perhaps diagnose from that.
If you don't I can figure out how to get it, but I haven't used mysql in
quite some time so I don't know offhand.
Howard
Mackenzie Brooks
Apr 8, 2013, 2:55:45 PM4/8/13
to bib...@googlegroups.com
Here's the schema from the works table. So it shouldn't have broken the publication date into three columns already?
+--------------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| type | varchar(255) | YES | MUL | NULL | |
| title_primary | text | YES | | NULL | |
| title_secondary | text | YES | | NULL | |
| title_tertiary | text | YES | | NULL | |
| affiliation | text | YES | | NULL | |
| volume | varchar(255) | YES | | NULL | |
| issue | varchar(255) | YES | | NULL | |
| start_page | varchar(255) | YES | | NULL | |
| end_page | varchar(255) | YES | | NULL | |
| abstract | text | YES | | NULL | |
| notes | text | YES | | NULL | |
| links | text | YES | | NULL | |
| work_state_id | int(11) | YES | MUL | NULL | |
| work_archive_state_id | int(11) | YES | | NULL | |
| publication_id | int(11) | YES | MUL | NULL | |
| publisher_id | int(11) | YES | MUL | NULL | |
| archived_at | datetime | YES | | NULL | |
| created_at | datetime | YES | | NULL | |
| updated_at | datetime | YES | | NULL | |
| original_data | text | YES | | NULL | |
| batch_index | int(11) | YES | MUL | 0 | |
| scoring_hash | text | YES | | NULL | |
| publication_date | date | YES | | NULL | |
| language | varchar(255) | YES | | NULL | |
| copyright_holder | text | YES | | NULL | |
| peer_reviewed | tinyint(1) | YES | | NULL | |
| machine_name | varchar(255) | YES | MUL | NULL | |
| publication_place | varchar(255) | YES | | NULL | |
| sponsor | varchar(255) | YES | | NULL | |
| date_range | varchar(255) | YES | | NULL | |
| identifier | varchar(255) | YES | | NULL | |
| medium | varchar(255) | YES | | NULL | |
| degree_level | varchar(255) | YES | | NULL | |
| discipline | varchar(255) | YES | | NULL | |
| instrumentation | varchar(255) | YES | | NULL | |
| admin_definable | text | YES | | NULL | |
| user_definable | text | YES | | NULL | |
| authority_publication_id | int(11) | YES | | NULL | |
| authority_publisher_id | int(11) | YES | | NULL | |
| initial_publication_id | int(11) | YES | | NULL | |
| initial_publisher_id | int(11) | YES | | NULL | |
| location | varchar(255) | YES | | NULL | |
| publication_date_year | int(11) | YES | | NULL | |
| publication_date_month | int(11) | YES | | NULL | |
| publication_date_day | int(11) | YES | | NULL | |
+--------------------------+--------------+------+-----+---------+----------------+
46 rows in set (0.07 sec)
--
You received this message because you are subscribed to the Google Groups "bibapp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+unsubscribe@googlegroups.com.
Howard Ding
Apr 8, 2013, 3:11:36 PM4/8/13
to bib...@googlegroups.com
Hi,
Yes, but I suspect what happened is this (refer to db/migrate20111111201022_split_publication_date_in_works.rb - a lot of the following is just background; if you want my proposed solution go to the end):
-------------------------
Here's how the migration is supposed to work:
1. The migration first creates the publication_date_year, publication_date_month, and publication_date_day columns.
2. For each Work it takes the existing publication_date, extracts the pieces, stuffs them into the new columns, and saves the work.
3. Finally it removes the publication_date column.
The initial error you got happened in step 2 - when the work was being saved with the split up publication_date_xyz information a callback was being fired that expected the work to have a sort_name, but that wasn't added until a later migration. So my initial patch bypassed the firing of this callback. When this error is triggered the whole migration should be cancelled and the table should have been rolled back to its previous form (i.e. without the new columns) (in database parlance, the entire migration is run in a transaction, and any error should cause a ROLLBACK).
Well, since we see both the new publication_date_xyz fields and the publication_date field, it appears that this didn't happen. My guess is that this has something to do with how MySQL is configured or how transactions work in it. In the deep past it didn't even have transactions, so I would have expected this behavior. I suspect it's still possible to set it up so that it doesn't. Maybe that happened. Or maybe it deals with transactions in a way sufficiently different than Postgres that this could have happened.
-----------------------------
My guess is that you will be fine if you do either (but not both!) of the following things:
- delete the publication_date_year, _month, and _day columns and rerun the migration
- in the above referenced migration file (db/migrate/20111111201022_split_publication_date_in_works.rb), comment out (locally on your installation) the lines that create these columns:
#add_column :works, :publication_date_year, :integer
#add_column :works, :publication_date_month, :integer
#add_column :works, :publication_date_day, :integer
and then rerun the migration
Please forgive my relative ignorance of MySQL - it was actually this sort of thing that made me switch to Postgres over ten years ago, and while my understanding is that it's a lot better now, I've used it so little that my knowledge is quite patchy.
Howard
Yes, but I suspect what happened is this (refer to db/migrate20111111201022_split_publication_date_in_works.rb - a lot of the following is just background; if you want my proposed solution go to the end):
-------------------------
Here's how the migration is supposed to work:
1. The migration first creates the publication_date_year, publication_date_month, and publication_date_day columns.
2. For each Work it takes the existing publication_date, extracts the pieces, stuffs them into the new columns, and saves the work.
3. Finally it removes the publication_date column.
The initial error you got happened in step 2 - when the work was being saved with the split up publication_date_xyz information a callback was being fired that expected the work to have a sort_name, but that wasn't added until a later migration. So my initial patch bypassed the firing of this callback. When this error is triggered the whole migration should be cancelled and the table should have been rolled back to its previous form (i.e. without the new columns) (in database parlance, the entire migration is run in a transaction, and any error should cause a ROLLBACK).
Well, since we see both the new publication_date_xyz fields and the publication_date field, it appears that this didn't happen. My guess is that this has something to do with how MySQL is configured or how transactions work in it. In the deep past it didn't even have transactions, so I would have expected this behavior. I suspect it's still possible to set it up so that it doesn't. Maybe that happened. Or maybe it deals with transactions in a way sufficiently different than Postgres that this could have happened.
-----------------------------
My guess is that you will be fine if you do either (but not both!) of the following things:
- delete the publication_date_year, _month, and _day columns and rerun the migration
- in the above referenced migration file (db/migrate/20111111201022_split_publication_date_in_works.rb), comment out (locally on your installation) the lines that create these columns:
#add_column :works, :publication_date_year, :integer
#add_column :works, :publication_date_month, :integer
#add_column :works, :publication_date_day, :integer
and then rerun the migration
Please forgive my relative ignorance of MySQL - it was actually this sort of thing that made me switch to Postgres over ten years ago, and while my understanding is that it's a lot better now, I've used it so little that my knowledge is quite patchy.
Howard
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+un...@googlegroups.com.
To post to this group, send email to bib...@googlegroups.com.
Visit this group at http://groups.google.com/group/bibapp?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "bibapp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+un...@googlegroups.com.
Mackenzie Brooks
Apr 8, 2013, 3:41:25 PM4/8/13
to bib...@googlegroups.com
Thanks Howard, that worked. So do you recommend that I switch to Postgre? I had only been using MySQL because I was marginally more familiar. And thank you for the background info, it helps a n00b like me.
Next question:
This appeared before the upgrade to 2, but after the Rails security update.
Instead of seeing the bibapp logo image when I have my local install running, I see exposed code: Application Name" src="/images/bibapp.png?1364397346" />
Here's the full tag:
<a href="/works"><img alt="<span class="translation_missing" title="translation missing: en.personalize.application_name">Application Name</span>" src="/images/bibapp.png?1364397346" /></a>
Where would this be coming from? I have changed the personalize.rb file, but it's not pulling that info.
Thanks again.
Mackenzie Brooks
Apr 8, 2013, 4:03:58 PM4/8/13
to bib...@googlegroups.com
Nevermind, I noticed the notes in that file were directing me to the locales folder. Editing the en.yml file fixed it.
Howard Ding
Apr 8, 2013, 4:47:41 PM4/8/13
to bib...@googlegroups.com
On 4/8/2013 2:41 PM, Mackenzie Brooks wrote:
> Thanks Howard, that worked. So do you recommend that I switch to
> Postgre? I had only been using MySQL because I was marginally more
> familiar. And thank you for the background info, it helps a n00b like me.
>
>
I don't really want to start a postgres/mysql flamewar based on my
> Thanks Howard, that worked. So do you recommend that I switch to
> Postgre? I had only been using MySQL because I was marginally more
> familiar. And thank you for the background info, it helps a n00b like me.
>
>
ten-year old stale understanding of mysql. :-) I thought Postgres was
better suited to my needs ten years ago, and it's still much more than
adequate for things that I do. There's no reason that I know of that
mysql shouldn't work fine with Bibapp, and I know other people use it -
perhaps if any have been following this who are experts they could chime
in on what may have happened.
Since we do use postgres here it is a lot more likely that we'll pick up
a problem early on - when there is a mysql issue I'm only going to learn
about it when someone else complains.
Howard
Mackenzie Brooks
Apr 8, 2013, 5:12:45 PM4/8/13
to bib...@googlegroups.com
Thanks, I'll keep that in mind.
So before the update, I had been trying to load authors via CSV. Now when I visit that page, I get an error page.
Started GET "/people/batch_csv_show" for 127.0.0.1 at 2013-04-08 15:44:10 -0500
Processing by PeopleController#batch_csv_show as HTML
User Load (0.4ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1
Role Load (0.3ms) SELECT `roles`.* FROM `roles` WHERE (name = 'admin' and authorizable_type = 'System' and authorizable_id IS NULL) LIMIT 1
Role Exists (0.3ms) SELECT 1 AS one FROM `roles` INNER JOIN `roles_users` ON `roles`.`id` = `roles_users`.`role_id` WHERE `roles_users`.`user_id` = 1 AND `roles`.`id` = 1 LIMIT 1
Rendered layouts/_main_body_no_h2.html.haml (2.2ms)
Rendered people/batch_csv_show.html.haml within layouts/application (3.6ms)
Completed 500 Internal Server Error in 113ms
ActionView::Template::Error (wrong number of arguments (3 for 2)):
1: .span-24
2: .span-22.prepend-1
3: = yield
app/views/people/batch_csv_show.html.haml:4:in `block in _app_views_people_batch_csv_show_html_haml__2709666818945873072_70187381852120'
app/views/layouts/_main_body_no_h2.html.haml:3:in `_app_views_layouts__main_body_no_h__html_haml___1356223546139481599_70187392808540'
app/views/people/batch_csv_show.html.haml:3:in `_app_views_people_batch_csv_show_html_haml__2709666818945873072_70187381852120'
--
You received this message because you are subscribed to the Google Groups "bibapp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+unsubscribe@googlegroups.com.
Howard Ding
Apr 8, 2013, 5:32:04 PM4/8/13
to bib...@googlegroups.com
I'll see what I can find out about
that, but it might not be until tomorrow.
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+un...@googlegroups.com.
To post to this group, send email to bib...@googlegroups.com.
Visit this group at http://groups.google.com/group/bibapp?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "bibapp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+un...@googlegroups.com.
Howard Ding
Apr 11, 2013, 5:12:01 PM4/11/13
to bib...@googlegroups.com
On 4/9/2013 4:36 PM, Mackenzie Brooks wrote:
> I got the full trace today and attached it. Looks like a syntax error.
> No rush, but thanks again.
>
I can replicate the problem. Someone else wrote the CSV import and I
> I got the full trace today and attached it. Looks like a syntax error.
> No rush, but thanks again.
>
don't think I've ever used it, but hopefully I can fix it without
breaking it. :-)
Howard
Mackenzie Brooks
Apr 11, 2013, 5:24:31 PM4/11/13
to bib...@googlegroups.com
That's always the challenge! For what it's worth, I was never able to get the original CSV import to work either. Thanks!
Howard
--
You received this message because you are subscribed to the Google Groups "bibapp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+unsubscribe@googlegroups.com.
Howard Ding
Apr 11, 2013, 7:11:57 PM4/11/13
to bib...@googlegroups.com
I can get it to work synchronously, but I'm having trouble getting it to
work as a delayed job. I thought maybe it'd be possible to dispense with
that, but if the number of persons being imported is fairly large (I
tried about 1000) it can take a few minutes, so better to leave it as
delayed if possible.
Hopefully I can finish it tomorrow.
Howard
work as a delayed job. I thought maybe it'd be possible to dispense with
that, but if the number of persons being imported is fairly large (I
tried about 1000) it can take a few minutes, so better to leave it as
delayed if possible.
Hopefully I can finish it tomorrow.
Howard
muz...@mskcc.org
Apr 12, 2013, 9:56:15 AM4/12/13
to bib...@googlegroups.com
Judging from the stack trace it looks like the haml file needs a comma between whater and :url.
I can't test anything since I'm still running on the Rails 2.3 version and don't have code working for 1.9.3 and Rails 3.
The "whather" seems a bit like a placeholder, I don't think it was in the original?
It also looks like the People controller was changed from the original and the routing is slightly different the batch import.
ERROR: compiling _app_views_people_batch_csv_show_html_haml__2709666818945873072_70187393447300 RAISED /Users/Administrator/Documents/Projects/Connect/BibApp/app/views/people/batch_csv_show.html.haml:4: syntax error, unexpected ':', expecting keyword_end
... form_for :person, 'whather' :url => batch_csv_create_peopl...
... ^
/Users/Administrator/Documents/Projects/Connect/BibApp/app/views/people/batch_csv_show.html.haml:4: syntax error, unexpected tASSOC, expecting tCOLON2 or '[' or '.'
...csv_create_people_url, :html => {:class=>"work_form", :metho...
________________________________________
From: bib...@googlegroups.com [bib...@googlegroups.com] on behalf of Howard Ding [had...@gmail.com]
Sent: Thursday, April 11, 2013 5:12 PM
To: bib...@googlegroups.com
Please note that this e-mail and any files transmitted from
Memorial Sloan-Kettering Cancer Center may be privileged, confidential,
and protected from disclosure under applicable law. If the reader of
this message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any reading, dissemination, distribution,
copying, or other use of this communication or any of its attachments
is strictly prohibited. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting this message, any attachments, and all copies and backups
from your computer.
I can't test anything since I'm still running on the Rails 2.3 version and don't have code working for 1.9.3 and Rails 3.
The "whather" seems a bit like a placeholder, I don't think it was in the original?
It also looks like the People controller was changed from the original and the routing is slightly different the batch import.
ERROR: compiling _app_views_people_batch_csv_show_html_haml__2709666818945873072_70187393447300 RAISED /Users/Administrator/Documents/Projects/Connect/BibApp/app/views/people/batch_csv_show.html.haml:4: syntax error, unexpected ':', expecting keyword_end
... form_for :person, 'whather' :url => batch_csv_create_peopl...
... ^
/Users/Administrator/Documents/Projects/Connect/BibApp/app/views/people/batch_csv_show.html.haml:4: syntax error, unexpected tASSOC, expecting tCOLON2 or '[' or '.'
...csv_create_people_url, :html => {:class=>"work_form", :metho...
________________________________________
From: bib...@googlegroups.com [bib...@googlegroups.com] on behalf of Howard Ding [had...@gmail.com]
Sent: Thursday, April 11, 2013 5:12 PM
To: bib...@googlegroups.com
Subject: Re: [bibapp] Re: Ruby 1.9.3/Rails 3.2 version now master, also tagged as bibapp-2.0.0
--
You received this message because you are subscribed to the Google Groups "bibapp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+un...@googlegroups.com.
To post to this group, send email to bib...@googlegroups.com.
Visit this group at http://groups.google.com/group/bibapp?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
=====================================================================
You received this message because you are subscribed to the Google Groups "bibapp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+un...@googlegroups.com.
To post to this group, send email to bib...@googlegroups.com.
Visit this group at http://groups.google.com/group/bibapp?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Please note that this e-mail and any files transmitted from
Memorial Sloan-Kettering Cancer Center may be privileged, confidential,
and protected from disclosure under applicable law. If the reader of
this message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any reading, dissemination, distribution,
copying, or other use of this communication or any of its attachments
is strictly prohibited. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting this message, any attachments, and all copies and backups
from your computer.
Howard Ding
Apr 12, 2013, 11:18:00 AM4/12/13
to bib...@googlegroups.com
On 4/12/2013 8:56 AM, muz...@mskcc.org wrote:
> Judging from the stack trace it looks like the haml file needs a comma between whater and :url.
> I can't test anything since I'm still running on the Rails 2.3 version and don't have code working for 1.9.3 and Rails 3.
> The "whather" seems a bit like a placeholder, I don't think it was in the original?
> It also looks like the People controller was changed from the original and the routing is slightly different the batch import.
>
I do have it fixed except for the delayed job part. I'm tempted to
> Judging from the stack trace it looks like the haml file needs a comma between whater and :url.
> I can't test anything since I'm still running on the Rails 2.3 version and don't have code working for 1.9.3 and Rails 3.
> The "whather" seems a bit like a placeholder, I don't think it was in the original?
> It also looks like the People controller was changed from the original and the routing is slightly different the batch import.
>
simply let it run synchronously, as this is an infrequently run
operation that is only run by administrators, and even doing a batch of
1000 only took a few minutes. But I do have a couple of other ideas
before it comes to that.
Howard
Howard Ding
Apr 12, 2013, 11:27:40 AM4/12/13
to bib...@googlegroups.com
In fact now that I think about it some more I'm going to go ahead and
push the synchronous patch so that it'll be available for Mackenzie and
then I'll get back to trying to figure it out for delayed job a little
later, as I have some other work that I need to get done and both of the
things that I think might be going wrong will take a little time to even
try fixes for.
I'll just need a few minutes to remove some debugging stuff that I have
in place and retest and then I'll push that.
Howard
push the synchronous patch so that it'll be available for Mackenzie and
then I'll get back to trying to figure it out for delayed job a little
later, as I have some other work that I need to get done and both of the
things that I think might be going wrong will take a little time to even
try fixes for.
I'll just need a few minutes to remove some debugging stuff that I have
in place and retest and then I'll push that.
Howard
Howard Ding
Apr 12, 2013, 11:34:45 AM4/12/13
to bib...@googlegroups.com
Okay, I've pushed the synchronous person csv import to master.
Mackenzie, you can pull that and give it a go again if you like.
When I get a chance I'll see if I can make it asynchronous again.
Howard
Mackenzie, you can pull that and give it a go again if you like.
When I get a chance I'll see if I can make it asynchronous again.
Howard
Mackenzie Brooks
Apr 12, 2013, 1:17:06 PM4/12/13
to bib...@googlegroups.com
That worked! Although it looks like the research_focus field was the only one that didn't import. Also, are the office address or phone number fields displayed anywhere or do they just live in the database?
Considering we do not even have 1000 faculty members, the delayed job is not a priority for us, but thanks again for all your hard work.
Howard
--
You received this message because you are subscribed to the Google Groups "bibapp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bibapp+unsubscribe@googlegroups.com.
muz...@mskcc.org
Apr 12, 2013, 1:32:18 PM4/12/13
to bib...@googlegroups.com
Mackenzie,
You should probably look in the lib folder for a file named batchload_authors.rb which has some example mappings for csv column names.
At the very least I think you can if necessary revise the csv (or spreadsheet) column names so that the import will be a straight mapping from your data to BibApp.
It's been awhile so I don't know what the default fields are in BibApp.
But anything you import would be displayed if there is a column in BibApp; there is no data that's hidden in the database.
There is also a way in that same file to change the mappings if you can't revise your own columns.
Eric
--
Programmer Analyst, Virtual Library Services
MSK Research Library
Memorial Sloan-Kettering Cancer Center
From: Mackenzie Brooks <mackenzi...@gmail.com>
Reply-To: "bib...@googlegroups.com" <bib...@googlegroups.com>
Date: Friday, April 12, 2013 1:17 PM
To: "bib...@googlegroups.com" <bib...@googlegroups.com>
Subject: Re: [bibapp] Re: Ruby 1.9.3/Rails 3.2 version now master, also tagged as bibapp-2.0.0
Reply-To: "bib...@googlegroups.com" <bib...@googlegroups.com>
Date: Friday, April 12, 2013 1:17 PM
To: "bib...@googlegroups.com" <bib...@googlegroups.com>
Subject: Re: [bibapp] Re: Ruby 1.9.3/Rails 3.2 version now master, also tagged as bibapp-2.0.0
To unsubscribe from this group and stop receiving emails from it, send an email to
bibapp+un...@googlegroups.com.
To post to this group, send email to bib...@googlegroups.com.
Visit this group at http://groups.google.com/group/bibapp?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
=====================================================================
Please note that this e-mail and any files transmitted from
Memorial Sloan-Kettering Cancer Center may be privileged, confidential,
and protected from disclosure under applicable law. If the reader of
this message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any reading, dissemination, distribution,
copying, or other use of this communication or any of its attachments
is strictly prohibited. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting this message, any attachments, and all copies and backups
from your computer.
Reply all
Reply to author
Forward
0 new messages