Support Arrays

[sebmiq]

I was trying to check out this project using my local db, but I get a panic with not convered: ArrayType(Int) in rustorm-0.10.5/src/pg/column_info.rs:203:30.

[ivanceras]

Ah yes, I skimmed through common data types, I added support for ArrayType(Text) since it is in sakila example. I'll add ArrayType(Int) soon. Thanks for testing out.

[ivanceras]

The specific commit is here ivanceras/rustorm@1324c9a

[ivanceras]

I just published a new version of rustorm@0.10.6 with support for some ArrayType for int[], float[], text[] variants.
You could try to reinstall the cli with

cargo +nightly install -f diwata_cli

See if it doesn't panic anymore. If it does, then most likely your database is using data types that has not supported yet.

[sebmiq]

Thanks for the quick reply.

Unfortunately, I still get a panic: unable to parse integer value: Err(ParseIntError { kind: Empty }), Error:ParseIntError { kind: Empty }', rustorm-0.10.6/src/pg/column_info.rs:216:47

Here's my table:

       Column         |       Type        |                     Modifiers                     | Storage  | Stats target | Description 
-----------------------+-------------------+---------------------------------------------------+----------+--------------+-------------
 id                    | integer           | not null default nextval('exos_id_seq'::regclass) | plain    |              | 
 origin                | character varying |                                                   | extended |              | 
 difficulty            | integer           |                                                   | plain    |              | 
 topic                 | character varying | not null                                          | extended |              | 
 subtopic              | character varying | not null                                          | extended |              | 
 comment               | character varying |                                                   | extended |              | 
 toknow                | boolean           |                                                   | plain    |              | 
 interesting           | boolean           |                                                   | plain    |              | 
 lesser                | integer[]         | default '{}'::integer[]                           | extended |              | 
 related               | integer[]         | default '{}'::integer[]                           | extended |              | 
 topics                | text[]            |                                                   | extended |              | 
 subtopics             | text[]            |                                                   | extended |              | 
 subsubtopic           | text              |                                                   | extended |              | 
 textsearchable_vector | tsvector          |                                                   | extended |              | 
 pm                    | smallint          | default 0                                         | plain    |              | 
 favorite              | boolean           | default false                                     | plain    |              | 
Indexes:
    "exos_pkey" PRIMARY KEY, btree (id)
    "textsearch_idx" gin (textsearchable_vector)

I'm not sure if the panic is an issue with array support, or with the tsvector type. If it's the latter, it may be more reasonable to just ignore columns with unsupported types ?

[ivanceras]

It looks like the default integer value {} is empty array which I haven't take into consideration, this should be an easy fix.
I already had support for tsvector, so it wouldn't be a problem. As an early version, I prefer the app to panic in the mean time, since this is the fastest way to fix things right away. I'll have to return proper error when most of the types are already covered.

[ivanceras]

This commit ivanceras/rustorm@bdfcdeb should fix the panic for empty array defaults. Please try to reinstall the diwata_cli to see if it works now. I'm betting this would work if you don't have anymore uncommon database types used in your design.

[sebmiq]

Looking good, thanks !