ckdake / setler Goto Github PK

Would be nice if the "thing id" = null's out there that are generally application level settings were somehow cacheable to avoid invoking a query every time the setting needed to be checked.

Starts to add up after a while in a high traffic app especially if there are multiple settings per page. Is there any way to do that currently? I didn't see it in the README.

class User < ActiveRecord::Base
  has_setler :preferences
end

class Preferences < Setler::Settings
end

# in an initializer
Preferences.defaults[:beta_notice] = true

After creating a new user:

> User.last.preferences.beta_notice
 Setler::ScopedSettings Load (0.7ms)  SELECT "preferences".* FROM "preferences" WHERE "preferences"."var" = 'bid_notification' AND (("preferences"."thing_type" = 'User' AND "preferences"."thing_id" = 7)) LIMIT 1
=> nil
>

Given a setting Settings.show_shiny_badges it would be awesome to be able to query them as predicates via something like Settings.show_shiny_badges? which doesn't appear to currently be a thing. In this case it would simply return the truthiness of the value but it may still add some value and read like idiomatic Ruby while we're at it?

Thoughts?

It works when false is set in the defaults, but not if it is set at runtime.

I think this is the issue (in settings.rb):

def self.[](var)
  the_setting = thing_scoped.find_by_var(var.to_s)
  the_setting.try(:value) || @@defaults[var]
end

I'm not sure how you want to deal with nil values, should setting it to nil mean that it goes back to default? If so, this would be correct:

def self.[](var)
  the_setting = thing_scoped.find_by_var(var.to_s)
  val = the_setting.try(:value)
  val.nil? ? @@defaults[var] : val
end

I will submit a patch with tests, but I think the README should be explicit about the behavior. Also, changing that would be a breaking change for some people, I imagine (though I think only people who were depending on setting something false returning true). Let me know! For now, I will just patch it in my Settings class. :)

Should

class User < ActiveRecord::Base
  has_setler as: :settings
end

Really be:

class User < ActiveRecord::Base
  has_setler :settings
end

?

Due to Setler's use of attr_protected instead of strong parameters, Rails 4 complains. Can we update Setler to be compatible with both models and no thinking?

We're upgrading an app from Rails 3.2 to 4.2 and running into issues with setler v0.0.13. Are there any plans to update this library with Rails 4/5 compatibility, or is this project considered dead?

Ruby:

user.preferences.testsetting = false

Postgres Error:

PG::InvalidTextRepresentation: ERROR:  invalid input syntax for integer: "testsetting"
: SELECT  "preferences".* FROM "preferences" WHERE "preferences"."thing_type" = $1 AND "preferences"."thing_type" = $2 AND "preferences"."thing_id" = $3 AND "preferences"."thing_id" = $4 AND "preferences"."
var" = $5 LIMIT 1

It'd be neat (e.g., for a Sinatra service I'm working on now) if Setler's generator script worked with any project that uses ActiveRecord, and not by requiring access to the Rails migration/generator libraries.

Is this intended? I can't tell because it seems bad, but test_user_settings_all seems to imply it's expected.

class Foo < Setler::Settings
end

class Bar < Setler::Settings
end

Foo.defaults[:foo] = "bar"
Bar.defaults[:foo] # returns "bar"

Now getting this message warning: instance variable @object not initialized
79 times for lines 54, 55, 60, and 61 of lib/setler/settings.rb for all versions of rails.

subject

is project supposed to run on ruby 1.8.7?

Not sure if this is "working as designed". My scenario is:

I've created some unscoped settings:

Featureflags.all_settings is set to { "test": true }

however

Featureflags.defaults is still returns {}

so my scoped settings(e.g., myobject.featureflags.all_settings) become {} as well.

An easy fix is:

Featureflags.defaults = Featureflags.all_settings

Not exactly sure when to call this(can't put it in an initializer since it depends the database already existing).

Now, myobject.featureflags.all_settings returns { "test": true }

I can see how the existing functionality would allow more flexible scenarios, but it is confusing enough that it might warrant a short explanation in the readme. Thoughts?

test_multithreaded_create test in test/settings_test.rb is failing
on my system (Ubuntu 14.04) but not on Travis. This is the error message:

SettingsTest#test_multithreaded_create [.../Projects/setler/test/settings_test.rb:83]:
[ActiveRecord::RecordNotUnique] exception expected, not
Class: <ActiveRecord::StatementInvalid>
Message: <"SQLite3::ConstraintException: UNIQUE constraint failed:
settings.var: INSERT INTO \"settings\" (\"created_at\", \"thing_id\",
\"thing_type\", \"updated_at\", \"value\", \"var\") VALUES (?, ?, ?, ?, ?, ?)">
---Backtrace---

Unclear how to fix it, but wanted to document it.
Running the same code as @ckdake's master

Add support for testing multiple versions of Rails, such as Rails 3, Rails 4, and Rails 5/edge.

It'd be nice if Setler followed a pattern like https://github.com/svenfuchs/i18n so we could use something better/faster/stronger like TokyoCabinet or Redis (optionally) to store settings instead of storing them directly in ActiveRecord in a relational DB

Just recently started getting LOTS of this: DEPRECATION WARNING: update_attributes is deprecated and will be removed from Rails 6.1

This is just an acknowledgement and a place to document research and further work.