I want to save data like this:
User.create(name:"Guy", properties:{url:["url1","url2","url3"], street_address:"asdf"})
Can I do so in Rails 4? So far, I have tried migration:
add_column :users, :properties, :hstore, array: true
But when I save the array in hstore, it returns error:
PG::InvalidTextRepresentation: ERROR: array value must start with "{" or dimension information
hstore is intended for simple key/value storage, where both the keys and values are simple unstructured strings. From the fine manual:
F.16. hstore
This module implements the store data type for storing sets of key/value pairs within a single PostgreSQL value. [...] Keys and values are simply text strings.
Note the last sentence: keys and values in hstore are strings. That means that you can't put an array in an hstore value without some handholding to convert the array to and from a string and you really don't want to be messing around with that sort of thing.
However, there is a JSON data type available:
8.14. JSON Type
The json data type can be used to store JSON (JavaScript Object Notation) data, as specified in RFC 4627.
and JSON can easily handle embedded arrays and objects. Try using JSON instead:
add_column :users, :properties, :json
You'll have to remove the old hstore column first though.
Also, you didn't want array: true on your hstore column as you weren't storing an array of hstores, you just wanted one of them.
Add on Mu's answer. Hstore is also giving very promising update in a few month (Postgresql 9.4 will launch in 3rd quarter of 2014).
Some highlights of the coming changes which should address these limitations:
Support for scalars and types (numeric, boolean, strings, NULL)
support, along with new corresponding operators
Support for nesting and arrays (the authors propose that output
format, i.e. brackets v. curly braces, be configured with GUC
variables)
Essentially, full compatibility between hstore and JSON, so JSON
documents can now take full advantage of hstore’s indexes (with GIN
in particular, the authors ballparked a 120x speed improvement for
JSON search performance)
It is very hard to pick one between hstore and json right now. Because they are just getting way too similar and updating too quickly.
My 2 cents to Mu's answer. I'm posting this as an answer cause I don't have enough reputation to add a comment.
JSON is becoming the go-to solution for storing "complex" data.
Oleg Bartunov--one of the authors of hstore--himself stated that there is no advantage using hstore over JSON and he encourages people use jsonb.
On Mar 23, 2014 jsonb, a structured format for storing json, was formally introduced in the pgsql development mailing list.
On May 15, 2014 JSONB was listed in the PostgreSQL 9.4 Beta 1 release announcement.
JSONB: 9.4 includes the new JSONB "binary JSON" type. This new storage format for document data is higher-performance, and comes with indexing, functions and operators for manipulating JSON data.
Related
i'm using io.confluent.connect.avro.AvroData.fromConnectData to convert message before serialization.
AvroData uses struct.get(field) to get values which in turn replaces nulls with schema default values.
as i understand from avro doc default values should be used for schema compatibility when reader expects field that missing in writer schema (not particular message).
so my question is: is it correct way to replace nulls with schema default value? or maybe i should use another way to convert messages?
The miss understanding is that the default value is not used to replace null values, it is used to populate your field value in case that your data does not include the field. This is primary used for schema evolution purposes. What you are trying to do (replace null values coming as part of your data with another value) is not possible through avro schemas, you will need to deal with it in your program.
Im working on a database table that consists of two columns - one for all the values I'd like to store converted to strings. And as for the other one, I'd like to store their original datatypes.
I understand that I can store their types in strings (e.g. "string", "fixnum" etc). However, when I need to retrieve and process that data later on I'll have to switch the types (I'd like to avoid that and to be able to convert the values back to their original types immediately.) Is there any way to store what we get from the .class call to a database column? And if so, of what type should the column be?
Thanks.
You can use the constantize method. It takes a string and tries to convert it to a constant name:
"String".constantize #becomes String
Now, the string has to be correctly capitalized for it to work. And if something is wrong, it throws an error. Use safe_constantize to make it return nil when it fails.
To use uisearchdisplaycontroller to specify a search on specific array fields, I found that the syntax caters only to key-value (dictionary?) data. Now, when I need to sort an array, I see again that the methods cater to key references, not mere array indexing. (I've built complex data with keyless arrays, not dictionaries.) Do I understand correctly that I should default to using dictionaries everywhere? Is there any situation to use plain arrays?
I see now the Key-Value Coding Guide (document 1812 of 3894)... should get to it any minute now.
It is NOT mandatory but it will be much comfortable when using NSDictionary.
Also, with the plain array, you can sort it as well without using "%K" at predicate format or using block comparator
I have a JSON data feed where the value is a hash if single value and is an array if there are multiple values (see JSON data below).
JSON data:
# multiple values in option
{"options":{"option":[{"$t":"hasShots"},{"$t":"housebroken"}]}
# single value in option
{"options":{"option":{"$t":"hasShots"}}
I can do a check to see if the value is a hash or array using is_a? in Ruby, then extract the data accordingly and convert it to an object. Is this how it would typically be done or is there a better, more elegant way to code it in Ruby?
(NB: I figure this is such a common thing that there might be good solution to handling it. I google but it kept giving me how to parse JSON data's and creating JSON in Rails.)
I can do a check using is_a?. Is this how it would typically be done?
That's how I would do it! I think the more common scenario is for the JSON (or whatever) to have a consistent design, and have the objects in an array even if there's just one.
I want to save data like this:
User.create(name:"Guy", properties:{url:["url1","url2","url3"], street_address:"asdf"})
Can I do so in Rails 4? So far, I have tried migration:
add_column :users, :properties, :hstore, array: true
But when I save the array in hstore, it returns error:
PG::InvalidTextRepresentation: ERROR: array value must start with "{" or dimension information
hstore is intended for simple key/value storage, where both the keys and values are simple unstructured strings. From the fine manual:
F.16. hstore
This module implements the store data type for storing sets of key/value pairs within a single PostgreSQL value. [...] Keys and values are simply text strings.
Note the last sentence: keys and values in hstore are strings. That means that you can't put an array in an hstore value without some handholding to convert the array to and from a string and you really don't want to be messing around with that sort of thing.
However, there is a JSON data type available:
8.14. JSON Type
The json data type can be used to store JSON (JavaScript Object Notation) data, as specified in RFC 4627.
and JSON can easily handle embedded arrays and objects. Try using JSON instead:
add_column :users, :properties, :json
You'll have to remove the old hstore column first though.
Also, you didn't want array: true on your hstore column as you weren't storing an array of hstores, you just wanted one of them.
Add on Mu's answer. Hstore is also giving very promising update in a few month (Postgresql 9.4 will launch in 3rd quarter of 2014).
Some highlights of the coming changes which should address these limitations:
Support for scalars and types (numeric, boolean, strings, NULL)
support, along with new corresponding operators
Support for nesting and arrays (the authors propose that output
format, i.e. brackets v. curly braces, be configured with GUC
variables)
Essentially, full compatibility between hstore and JSON, so JSON
documents can now take full advantage of hstore’s indexes (with GIN
in particular, the authors ballparked a 120x speed improvement for
JSON search performance)
It is very hard to pick one between hstore and json right now. Because they are just getting way too similar and updating too quickly.
My 2 cents to Mu's answer. I'm posting this as an answer cause I don't have enough reputation to add a comment.
JSON is becoming the go-to solution for storing "complex" data.
Oleg Bartunov--one of the authors of hstore--himself stated that there is no advantage using hstore over JSON and he encourages people use jsonb.
On Mar 23, 2014 jsonb, a structured format for storing json, was formally introduced in the pgsql development mailing list.
On May 15, 2014 JSONB was listed in the PostgreSQL 9.4 Beta 1 release announcement.
JSONB: 9.4 includes the new JSONB "binary JSON" type. This new storage format for document data is higher-performance, and comes with indexing, functions and operators for manipulating JSON data.