datamapper / dm-postgres-adapter Goto Github PK
View Code? Open in Web Editor NEWA postgresql Adapter for DataMapper
Home Page: http://datamapper.org/
License: MIT License
A postgresql Adapter for DataMapper
Home Page: http://datamapper.org/
License: MIT License
the record
class Testing
include DataMapper::Resource
property :id, DataMapper::Property::Serial
property :email, String, unique_index: true
property :password, Binary, length: 64 # for SHA-512
end
DataMapper.finalize
DataMapper.auto_migrate!
the error message
~ (0.000329) CREATE TABLE "testings" ("id" SERIAL NOT NULL, "email" VARCHAR(50), "password" BYTEA(64), PRIMARY KEY("id"))
~ ERROR: type modifier is not allowed A (code: 16801924, sql state: 42601, query: CREATE TABLE "testings" ("id" SERIAL NOT NULL, email" VARCHAR(50), "password" BYTEA(64), PRIMARY KEY("id")), uri: postgres:[email protected]/aya?scheme=postgres&user=ayayay&password=wrong_password&host=127.0.0.1&port=&path=/aya&query=&fragment=&adapter=postgres)
~ (0.000102) RESET client_min_messages
/home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/adapters/dm-do-adapter.rb:100:in `execute_non_query': ERROR: type modifier is not allowed A (DataObjects::SyntaxError)
the version
$ psql --version
psql (PostgreSQL) 9.2.4
$ gem list | grep data_mapper
data_mapper (1.2.0)
$ ruby --version
ruby 2.0.0p247 (2013-06-27 revision 41674) [i686-linux]
$ jruby --version
jruby 1.7.4 (2.0.0) 2013-05-16 2390d3b on OpenJDK Server VM 1.7.0_40-b31 +indy [linux-i386]
$ uname -a
Linux unusual 3.10.5-1-pae #1 SMP PREEMPT Tue Aug 6 18:31:23 EDT 2013 i686 GNU/Linux
the stack trace:
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/adapters/dm-do-adapter.rb:100:in `block (2 levels) in create_model_storage'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/adapters/dm-do-adapter.rb:98:in `each'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/adapters/dm-do-adapter.rb:98:in `block in create_model_storage'
from /home/asd/.gem/ruby/2.0.0/gems/dm-do-adapter-1.2.0/lib/dm-do-adapter/adapter.rb:276:in `with_connection'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/adapters/dm-do-adapter.rb:93:in `create_model_storage'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/adapters/dm-postgres-adapter.rb:23:in `block in create_model_storage'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/adapters/dm-postgres-adapter.rb:58:in `without_notices'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/adapters/dm-postgres-adapter.rb:23:in `create_model_storage'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/auto_migration.rb:81:in `create_model_storage'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/auto_migration.rb:177:in `auto_migrate_up!'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/auto_migration.rb:132:in `auto_migrate!'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/auto_migration.rb:47:in `block in repository_execute'
from /home/asd/.gem/ruby/2.0.0/gems/dm-core-1.2.1/lib/dm-core/support/descendant_set.rb:64:in `block in each'
from /home/asd/.gem/ruby/2.0.0/gems/dm-core-1.2.1/lib/dm-core/support/subject_set.rb:211:in `block in each'
from /home/asd/.gem/ruby/2.0.0/gems/dm-core-1.2.1/lib/dm-core/support/ordered_set.rb:320:in `block in each'
from /home/asd/.gem/ruby/2.0.0/gems/dm-core-1.2.1/lib/dm-core/support/ordered_set.rb:320:in `each'
from /home/asd/.gem/ruby/2.0.0/gems/dm-core-1.2.1/lib/dm-core/support/ordered_set.rb:320:in `each'
from /home/asd/.gem/ruby/2.0.0/gems/dm-core-1.2.1/lib/dm-core/support/subject_set.rb:211:in `each'
from /home/asd/.gem/ruby/2.0.0/gems/dm-core-1.2.1/lib/dm-core/support/descendant_set.rb:63:in `each'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/auto_migration.rb:46:in `repository_execute'
from /home/asd/.gem/ruby/2.0.0/gems/dm-migrations-1.2.0/lib/dm-migrations/auto_migration.rb:22:in `auto_migrate!'
from /home/asd/.gem/ruby/2.0.0/gems/dm-constraints-1.2.0/lib/data_mapper/constraints/migrations/singleton_methods.rb:10:in `auto_migrate!'
the cause (on pry, irb, or source code), this line runs in 40-45 seconds:
DataMapper.setup(:default, 'postgres://myuser:[email protected]/mydbname')
additional info: http://stackoverflow.com/questions/19397577/slow-ruby-datamapper-setup
The host (Ubuntu with Intel i3 CPU): Linux 3.8.0-31-generic #46-Ubuntu SMP Tue Sep 10 20:03:44 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
The guest (ArchLinux, inside VMWare): Linux 3.11.1-2-ARCH #1 SMP PREEMPT Sun Sep 22 20:03:40 CEST 2013 i686 GNU/Linux
VMWare: 6.0.0 build-1295980
PostgreSQL: postgres (PostgreSQL) 9.3.1
dm-postgres-adapter: dm-postgres-adapter (1.2.0)
Ruby: ruby 2.0.0p247 (2013-06-27 revision 41674) [i686-linux]
JRuby: jruby 1.7.5 (1.9.3p392) 2013-10-07 74e9291 on OpenJDK Client VM 1.7.0_40-b60 [linux-i386]
slowness does not happened when using ActiveRecord, psql command line or when running the same guest on another host PC (ArchLinux with AMD APU CPU)
I could not find the place to change this timeout. Any pointers? Also, is there a way to check if there is still an active connection/tcp socket without going through a whole roundtrip (eg.g DataMapper::Repository.adapter.connection.alive?)?
This behavior is causing problems in combination with forked processes (e.g Resque workers). If the connection of the workers parents is no longer available, the child will open and close a connection for every item it processes. An ugly quick fix around this is to have the following in the workers master process (after_prefork hook):
Thread.new do
while true
DataMapper::Repository.adapters.keys.each do |repo|
DataMapper.repository(repo).adapter.select("SELECT 1;")
end
sleep 30
end
end
Hi,
I am using Puma, Sinatra, and dm-postgres-adapter with the following configuration. I am posting this issue on both Puma and dm-postgres-adapter.
configure do
enable :logging
DataMapper.setup(:default, {
adapter: 'postgres',
host: 'localhost',
pool: 5,
database: 'my_app_development'
})
DataMapper.finalize
DataMapper.auto_upgrade!
end
This configuration has erratic connection behavior. If I the fix the threads in Puma to 2:2 under load I get 5 connections, with 4:4 I get 6 connections, and the default 0:16 uses 13 connections.
I am using siege -c 100 -r 10. What is the expected behavior here?
Thanks.
See this test script.
This works as I expect with MySQL or SQLite.
Is this bug? Are there some workaround?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.