0

I have an app running on my Raspberry Pi with Postgresql 9.1.

My first iteration was to add weather records into a table called "Weathers". That was successful.

My next iteration is to use psychopg2 to write records from Python into a different table called "weather". That also is succcessful.

What should also be successful is to change the Weather class in my app to the new fields. But DataMapper returns a mapping error: 

@records = Weather.all(:order => :timestamp.desc)
ArgumentError at /
+options [:order]+ entry :timestamp does not map to a property in Weather

Rereading the datamapper.org docs suggests it's something to do with my table name so I migrated over the older "weathers" table into another called "older" and dropped the "weathers" table. But DataMapper still fails to find this table.

My Postgres environment with a truncated view of the target table is:

            List of relations
 Schema |   Name    | Type  | Owner 
--------+-----------+-------+-------
 public | customers | table | pi
 public | older     | table | pi
 public | systemlog | table | pi
 public | weather   | table | pi
(4 rows)

                                                         Table "public.weather"
           Column            |            Type             |                      Modifiers                       | Storage  | Description 
-----------------------------+-----------------------------+------------------------------------------------------+----------+-------------
 id                          | integer                     | not null default nextval('weather_id_seq'::regclass) | plain    | 
 timestamp                   | timestamp without time zone | default now()                                        | plain    | 
 currentwindspeed            | real                        |                                                      | plain    | 
 bmp180temperature           | integer                     |                                                      | plain    | 
Indexes:
    "weather_pkey" PRIMARY KEY, btree (id)
Has OIDs: no

My Datamapper class is:

class Weather
  include DataMapper::Resource
  property :id,  Serial
  property :bmp180temperature, String
  property :insidehumidity, String
  property :totalrain, String
  property :currentwinddirection, String
  property :currentWindSpeed, String
  property :timestamp, DateTime
end
DataMapper.finalize
Weather.auto_upgrade!

Since this is Ruby I fired-up IRb, required the Datamapper gem and got:

records = Weather.all
DataObjects::SyntaxError: ERROR:  column "bmp180temperature" does not exist
LINE 1: SELECT "id", "bmp180temperature", "insidehumidity", "totalra...
                     ^
 (code: 50360452, sql state: 42703, query: SELECT "id", "bmp180temperature", "insidehumidity", "totalrain", "currentwinddirection", "current_wind_speed", "timestamp" FROM "weathers" ORDER BY "id", uri: postgres:pi@localhost/postgres?scheme=postgres&user=pi&password=pw&host=localhost&port=&path=/postgres&query=&fragment=&adapter=postgres)
        from /var/lib/gems/1.9.1/gems/dm-do-adapter-1.2.0/lib/dm-do-adapter/adapter.rb:147:in `execute_reader'
        from /var/lib/gems/1.9.1/gems/dm-do-adapter-1.2.0/lib/dm-do-adapter/adapter.rb:147:in `block in read'
        from /var/lib/gems/1.9.1/gems/dm-do-adapter-1.2.0/lib/dm-do-adapter/adapter.rb:276:in `with_connection'

This makes me think it's not finding the right table. It seems to be OK with the id column, perhaps.

I see what appears to be DataMapper is being used for PHP in the CodeIgniter framework but I'm unsure if it's the same DataMapper I'm using in Ruby.

What am I overlooking to get DataMapper to find this table?

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
sam452
  • 1,281
  • 3
  • 20
  • 33
  • First, you need to understand your technology. Sinatra isn't the problem at all, it's your use of Datamapper. Sinatra only is the tool to display the output of Datamapper, and it's all running in Ruby code, so rewrite your question with that new knowledge so it makes more sense. "Datamapper" has been implemented for multiple languages; They're not the same so ignore the one for PHP. – the Tin Man Dec 23 '15 at 16:46
  • i agree that Sinatra isn't the cause, but merely how the error was first returned. Are you saying the first third of my Q relating the background/context should be removed? It seems the last 2/3 is where my Q resides (postgresql and datamapper)? – sam452 Dec 23 '15 at 17:01
  • I'm saying that your wording is distractingly misleading. "But Sinatra returns a mapping error:", "But Sinatra still fails to find this table.", "What am I overlooking to get Sinatra to find this table?" for instance. Sinatra doesn't find anything, it doesn't care, only Datamapper does. Take Sinatra out of the question entirely as it's an innocent bystander and its repeated mention is a red-herring. – the Tin Man Dec 23 '15 at 17:40

0 Answers0