Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

Add short-hand definition for PostgreSQL XML data type

#1874

I'm starting a project in rails that uses the XML data type in postgres.

The migration for that to work needs to be like this:


class CreateDocuments < ActiveRecord::Migration
  def self.up
    create_table :documents do |t|
      **t.column :data, :xml**

      t.timestamps
    end
  end

  def self.down
    drop_table :documents
  end
end

While with the new sexy migrations it should work like this as well:


class CreateDocuments < ActiveRecord::Migration
  def self.up
    create_table :documents do |t|
      **t.xml :data**

      t.timestamps
    end
  end

  def self.down
    drop_table :documents
  end
end

This small patch does only that.

Reported by Leonardo Borges · February 4th, 2009 @ 03:23 PM

State: committed
Milestone: 2.3.4
Assigned to: Jeremy Kemper Jeremy Kemper
Importance: none

Activity

  1. Pratik
    Pratik
    • Assigned user set to Tarmo Tänav

    February 18th, 2009 @ 04:21 PM

  2. Leonardo Borges
    Leonardo Borges
    • Tag set to patch

    Added proper patch diff to show the changes. Also the patch includes fix for the schema dumping.

    It was dumping as:

    t.string

    instead of:

    t.xml

    February 18th, 2009 @ 04:47 PM

  3. Tarmo Tänav
    Tarmo Tänav

    Shouldn't there be a fallback for other databases that don't have an XML type, so that a migration that in PostgreSQL uses xml falls back to string for example on mysql?

    February 18th, 2009 @ 05:46 PM

  4. Leonardo Borges
    Leonardo Borges

    I guess that depends.

    Attached is a possible solution within the same diff.

    This falls back to the sqltype :text for mysql and sqlite if trying to use the XML datatype. I chose :text as the default because if you're coming from a DB that supports XML, it's likely your data exceeds the limit of a varchar column, which is the one string defaults to.

    Also, other databases, such as oracle, have different types to handle such content. In fact, Oracle has a XML dataype which is named differently.

    My feeling is that moving away from a XML column shouldn't be that transparent because in such cases you're doing it for a very specific reason, such as spreading the XML content overr relational tables, in which case the former XML column would be dropped, or storing it as text for further processing, in which case, each database data type should be analyzed carefully to find a suitable match for the content.

    February 19th, 2009 @ 09:37 AM

  5. Leonardo Borges
    Leonardo Borges

    Small update to the patch.

    I forgot to add xml to the NATIVE_DATABASE_TYPES hash.

    With this change, this is the fully working patch I'm using here.

    February 20th, 2009 @ 08:20 AM

  6. Pedro Pimentel (zukunftsalick)
    Pedro Pimentel (zukunftsalick)

    I agree with Leonardo when he says you don´t need to be transparent in such cases, because for most of cases are situations where you are just moving away from XML and just want to keep the xml data column for legacy reasons.

    We need to remember that RAILS is a opinionated framework and I believe it´s fair to have that assumptions for this patch.

    February 23rd, 2009 @ 02:12 PM

  7. Philip MacIver
    Philip MacIver

    I think that this change needs to be applied. Also I have used it and it works fine. Also I created a 1 character fix so that escape characters within xml that is saved to the database in postgres get converted properly without throwing any deprecation warnings.

    March 9th, 2009 @ 01:01 PM

  8. Xavier Noria
    Xavier Noria

    I've worked with this patch for a couple of weeks. It works smoothly once Philip's is applied.

    I think this is a nice addition. Note that is consistent with TableDefinition#column, which is open by design to custom datatypes.

    A formal detail: I'd like the new arrow in the native datatype listing to be aligned with the rest.

    March 10th, 2009 @ 10:01 AM

  9. Pratik
    Pratik

    You should rebase all the patches into a single patch. And also, needs some tests.

    March 10th, 2009 @ 02:37 PM

  10. Leonardo Borges
    Leonardo Borges

    Combined changes in a single patch and added tests.

    March 11th, 2009 @ 02:47 PM

  11. Leonardo Borges
    Leonardo Borges

    So is it missing anything in the patch?

    Just wondering is you had time to take a look at it.

    Tks

    April 30th, 2009 @ 11:51 AM

  12. CancelProfileIsBroken
    CancelProfileIsBroken
    • Tag changed from patch to bugmash, patch

    August 6th, 2009 @ 02:19 PM

  13. Nikolay Petrachkov
    Nikolay Petrachkov

    I applied this above patch to master. No new fail test.
    I've attached patch for master branch.

    August 9th, 2009 @ 11:21 AM

  14. Jeremy Kemper
    Jeremy Kemper
    • Assigned user changed from Tarmo Tänav to Jeremy Kemper
    • State changed from new to open
    • Milestone changed from 2.x to 2.3.4

    Please avoid making whitespace changes in the same commit as a major feature. It makes merging difficult.

    August 10th, 2009 @ 06:27 AM

  15. Jeremy Kemper
    Jeremy Kemper
    • State changed from open to committed
    • Tag changed from bugmash, patch to patch

    August 10th, 2009 @ 06:29 AM

  16. Repository
  17. Repository