Jeff, thanks for your reply.
I tried what you suggested, but the results were the same. It always hangs
at the same place, so a bit more investigation and I found that the file it
fails on looks like this:
--- !ruby/object:DatePagePart
attributes:
name: enddate
page_part_type: DatePagePart
datetime_content: 2010-07-01 00:00:00
filter_id: ""
string_content:
page_id: "275"
boolean_content:
id: "2542"
integer_content:
content:
attributes_cache: {}
I think it's getting an incorrect object name, "DatePagePart" and I think It
should be "PagePart". The other files that load correctly from this same
folder look like:
--- !ruby/object:PagePart
attributes:
name: body
page_part_type:
datetime_content:
filter_id: ""
string_content:
page_id: "1"
boolean_content:
id: "1"
integer_content:
content: <r:assets:image title="Main background" />
attributes_cache: {}
Same attributes, but page_part_type is blank.
The page_part_type, datetime_content, string_content, boolean_content,
and integer_content attributes are from the page_parts extension. My guess
is the exporter function of the super_export extension that creates these
yml files is not handling the database records created by the page_parts
extension correctly. Why and how to fix it are beyond me. Can anyone help?
On Fri, Jun 18, 2010 at 12:24 PM, Jeff Casimir <[email protected]>wrote:
> I've had issues with YAML::Object when loading DB data before. Rails
> does lazy loading of classes, so they aren't available until
> explicitly used. The YAML loading process doesn't cause them to get
> loaded. You can get around this by explicitly requiring your models
> at the top of your script, or doing some hack like this:
>
> [Page, User, Attachment].each do |klass|
> klass.new
> end
>
> Then, when your import script is later converting the objects from
> YAML they'll become real ActiveRecord objects instead of that
> YAML::Object placeholder.
>
> - Jeff
>
> ---
> Jeff Casimir
> Jumpstart Lab by Casimir Creative, LLC
> http://jumpstartlab.com
> @jumpstartlab on twitter
>
> --
marshal
