Does anyone know how to resolve this deprecation? I have included the deprecation warning and the offending migration file.
DEPRECATION WARNING: ActiveRecord::Migrator.proper_table_name is deprecated and will be removed in Rails 4.2. Use the proper_table_name instance method on ActiveRecord::Migration instead. (called from change at project/db/migrate/20141010204446_add_state_to_uploads.rb:4)
# db/migrate/20141010204446_add_state_to_uploads.rb
class AddStateToUploads < ActiveRecord::Migration
def change
add_column :uploads, :state, :string, index: true
add_index :uploads, :state
end
end
Cite:
https://github.com/rails/rails/pull/15512
http://apidock.com/rails/v4.0.2/ActiveRecord/Migrator/proper_table_name/class
Simply use ActiveRecord::Migration.proper_table_name instead when you upgrade to Rails 4.2.
Apparently a resolution for the Warning message is not available in 4.0 or 4.1.
http://guides.rubyonrails.org/4_2_release_notes.html
Related
I get the following error message while reading strings. How could I overcome it or set it quient? Julia 0.6.
WARNING: Compat.UTF8String is deprecated, use String instead.
Thanks!
You can disable deprecation warnings by launching julia with the --depwarn=no option.
I was using QT5.4.1 version with the QWT-6.1.2 library that I've installed but in compiling I receive the error "QT_STATIC_CONST does not name a type". After some researsh how to fix that, I found that I should install the QT version 5.5.
I have that already achieved but the error appears although!
I use Kubuntu by the way
What should I do ?
QT_STATIC_CONST’ does not name a type.
By defining QT_STATIC_CONST just before inserting Qwt file, compilation works.
- In Qt5.4 , QT_STATIC_CONST was removed from qglobal.h
- Qwt 6.1.1 uses this macro, but fixed it in Qwt 6.1.2
Here is the content that was removed from qglobal.h that created this issue. Adding this to your code prior to including the header file should resolve the issue.
/*
Workaround for static const members on MSVC++.
*/
#if defined(Q_CC_MSVC)
# define QT_STATIC_CONST static
# define QT_STATIC_CONST_IMPL
#else
# define QT_STATIC_CONST static const
# define QT_STATIC_CONST_IMPL const
#endif
I'm playing with command model binding and I looked at the example github project and I have issues when using the dependency:
"org.scalatra" % "scalatra-data-binding" % "2.2.0-RC1"
Taking the example project code i.e.
abstract class TodosCommand[S](implicit mf: Manifest[S]) extends ModelCommand[S] with ParamsOnlyCommand
class CreateTodoCommand extends TodosCommand[Todo] {
val name: Field[String] = asType[String]("name").notBlank.minLength(3)
}
case class Todo(id: Integer, name: String, done: Boolean = false)
I am unable to compile when I use the command[CreateTodoCommand] method from the CommandSupport trait i.e.
scala: type arguments [au.com.xxx.sapi.seo.CreateTodoCommand] do not conform to method command's type parameter bounds [T <: SeoServlet.this.CommandType]
val cmd = command[CreateTodoCommand]
^
I'm not that clued up with Scala but I would assume that as ParamsOnlyCommand extends Command and there is this line in the command support trait, then there should be no issues:
type CommandType <: org.scalatra.databinding.Command
Any ideas why I am getting this issue?
Cheers, Chris.
It's very likely that the reason you're having problems is that we're still linking to an ancient example version, for which the docs no longer apply. I thought I'd caught all of the example projects in the docs and moved them into https://github.com/scalatra/scalatra-website-examples, but apparently I missed this one. Sorry for the hassle!
I'll see if I can fix this today sometime, and provide a compiling example. In the meantime, you might try updating all your Scalatra-related dependencies to the 2.2.0 release - and see if that fixes anything straight away.
The latest stable release of Scalatra is currently 2.2.1, but you'll need to be careful around commands as I remember #casualjim saying that he'd changed the way things worked to some extent between 2.2.0 and 2.2.1.
In Scalatra 2.2.1, "org.scalatra" %% "scalatra-commands" % "2.2.0" I have no issues. but I don't know scalatra-data-binding is also standalone.
In application.conf (in Play 2.0.4, sbt 0.11.3) I could use following substitutions:
app {
major = 0
minor = 1
revision = 62
date = 0127
version = ${app.major}.${app.minor}.${app.revision}.${app.date}
}
After upgrade to Play 2.1.0 and sbt 0.12.2 and using this suggestion for Build.scala,
val conf = ConfigFactory.parseFile(new File("conf/application.conf"))
I get error when I do play clean:
Caused by: com.typesafe.config.ConfigException$NotResolved: need to call resolve() on root config; tried to get value type on an unresolved substitution: ConfigSubstitution(${app.major}"."${app.minor}"."${app.revision}"."${app.date})
at com.typesafe.config.impl.ConfigSubstitution.valueType(ConfigSubstitution.java:54)
at com.typesafe.config.impl.DefaultTransformer.transform(DefaultTransformer.java:15)
at com.typesafe.config.impl.SimpleConfig.findKey(SimpleConfig.java:118)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:135)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:140)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:108)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:146)
at com.typesafe.config.impl.SimpleConfig.getString(SimpleConfig.java:188)
at ApplicationBuild$.<init>(Build.scala:12)
at ApplicationBuild$.<clinit>(Build.scala)
Based on Play Configuration documentation this kind of substitution should be supported:
Implementations must take care, however, to allow objects to refer to
paths within themselves. For example, this must work:
bar : { foo : 42,
baz : ${bar.foo}
} Here, if an implementation resolved all substitutions in bar as part of resolving the substitution ${bar.foo}, there would be a
cycle. The implementation must only resolve the foo field in bar,
rather than recursing the entire bar object.
Any ideas how to fix this?
Your syntax is correct. It seems that you actually need to call resolve() as the error message says, to resolve substitutions. I guess in 2.0.x the play framework did this and provided a config that was already resolved this way. Now that the config API is used directly it needs to be resolved manually.
Add a call to resolve() in this line:
val conf = ConfigFactory.parseFile(new File("conf/application.conf")).resolve()
AFAIK, my understanding of the doc is that you should use something like:
app {
major = 0
minor = 1
revision = 62
date = 0127
version = ${major}.${minor}.${revision}.${date}
}
I did not test it...
And maybe it worked under 2.0.4 because of a bug ?
After adding unweb.watermark to eggs, I get an endless series of starts in instance.log (Plone 4.1.2), but no service.
See buildout / fg at http://pastie.org/2776226
How can I investigate/fix this?
By adding that product in a vanilla Plone I've faced these two issues (depending on the versions of products used):
ConfigurationError: ('Unknown directive', u'http://namespaces.zope.org/tales', u'expressiontype')
or
AttributeError: type object 'DirectoryResource' has no attribute
'resource_factories'
In order to fix that issue you should extend your buildout like this:
[buildout]
...
extends =
...
http://svn.plone.org/svn/collective/unweb.watermark/trunk/versions.cfg
http://good-py.appspot.com/release/plone/4.1.2?dexterity=1.0
More info:
http://www.gossamer-threads.com/lists/zope/dev/230509
http://code.google.com/p/dexterity/issues/detail?id=165