Rack::Lint::LintError: Status must be >=100 seen as integer - sqlite

I am using the DataMapper gem with Sinatra and followed the tutorial here:
http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-working-with-datamapper/
I am connecting to the database and migrating as such:
DataMapper.setup :default, "sqlite://#{Dir.pwd}/ex2.db"
DataMapper.auto_migrate!
My data model:
class User
include DataMapper::Resource
property :id , Serial
property :username , String
property :email , String
end
I am executing using this command:
rackup config.ru
However, when I get to this line:
User.create username: "JoeSchmo", email: "joe#schmo.com"
I receive the error:
Rack::Lint::LintError: Status must be >=100 seen as integer
Any idea why this is happening?

Try deleting the SQLite DB - there seems to be a bug in data_mapper with changing the data structure and using old data. For me the bug went away after deleting the db and setting up a new one.

What version of ruby are you on because if you are on less than 1.9 you have to use the => hash constructor not : and move the colon to the beginning because it is a symbol.
User.create :username => "JoeSchmo", :email => "joe#schmo.com"

I had the same problem with Sinatra and datamapper. Creating my records with "new" keyword rather than "create" and then adding attributes one by one worked for me. Hope you find it useful.

Related

custom module installation error on odoo 14

ValueError: ir.actions.report.report_type: required selection fields must define an ondelete policy that implements the proper cleanup of the corresponding records upon module uninstallation. Please use one or more of the following policies: 'set default' (if the field has a default defined), 'cascade', or a single-argument callable where the argument is the recordset containing the specified option.
You need to declare like this :
report_type = fields.Selection(
selection_add=[('sale', 'sale')],
ondelete={'sale': 'cascade'}
)
or you can also add this as per the requirement :
ondelete={'sale': 'set default'})
If you guys get this issue when database is cached, then try this (otherwise, ignore this solution):
Add dbfilter to odoo.conf:
dbfilter = ^your_db_name*
Then restart the server and go to /web/database/selector and select your db

Error during compiling: `identifier not found` (code C3861)

I have a field in my acore_characters table named 'rank' with a tinyint which ranges from 0 to 3 inclusive, based on player's progression. I need to read that value at both login and at certain specific circumstances.
I wrote the following PreparedStatement: "SELECT rank FROM acore_characters WHERE guid = ?" and then the code which is supposed to read that value:
uint16 GetCharactersRank(uint64 guid) {
PreparedStatement* stmt = CharacterDatabase.GetPreparedStatement(mystatement);
stmt->setUInt32(0, GetGUID());
PreparedQueryResult result = CharacterDatabase.Query(stmt);
if (result) {
[...truncated]
and then fetching the result and so on, but then I get a code C8361 when compiling because 'GetGUID':identifier not found in Player.cpp file...what goes wrong? The other GetGUID calls throughout the file dont give this result. I'm not very fond of c++, any help is very appreciated.
It's not recommended to directly patch the core to add customisations to it. Instead, use modules.
An example can be found here: Is it possible to turn a core patch into a module for AzerothCore?
You can have a look and copy the skeleton-module and start modifying it to create your own.
In your case, you probably want to use the OnLogin player hook.

Navigations can only target entity types with keys

I am working on a project with a 'database first' approach rest API backend. I am using ASP .Net Core 3.1 and Entity Framework 3.1.1.
I ran a script to scaffold the database into the models and db context class. However, some of the model building functions have tables/models without keys x.hasnokey(). I thought this would be fine but I get an error trying to hit the endpoint that states
ERROR : InvalidOperationException:
The navigation '' cannot be added because it targets the keyless entity type 'AAA'
Navigations can only target entity types with keys
This happens in a few different locations and this originally ran okay in the past. This is running on SQL Server 2012 (version 11). I am not sure how I can solve this issue, I have limited entity/sql experience and I just don't know where to begin. Here is the offending lines (inside DB Context):
modelBuilder.Entity<AAA>(entity =>
{
entity.HasNoKey();
entity.ToTable("BBB_AAA");
entity.HasOne(d => d.BBB)
.WithMany(p => p.AAA)
.HasForeignKey(d => d.CCC)
.OnDelete(DeleteBehavior.ClientSetNull)
...
}
The script I used to scaffold the models and db context was (generic version):
PM> Scaffold-DbContext "Server=.\SQLExpress;Database=SchoolDB;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models
I believe this might be that the database that was originally created about 10-15 years ago, cannot be made into an ORM so easily as I would have hoped. It could also a versioning issue, the scaffolding script I ran is incorrect, or if I just am out of my depth but I would appreciate being pointed in the right direction. Thank you!
This error usually comes because of Primary Key issue.
In my Case I was running this query and result was same problem you mentioned
var exists = await _dbDontext.Students.FindAsync(Id);
My Student table has relations with other tables and one of other tables was missing Primary Key.
So two Possible Solutions .
Solution 1 :
Make Primary Key column in your table that is mentioned in your error.
Solution 2 :
If things are complicated , just delete the table and Re Create It. It would work fine
I think you have two options,
1- Go and add key to the table.
2- check the following link
https://learn.microsoft.com/en-us/ef/core/modeling/keyless-entity-types
Thanks

CosmosDB - Entity Framework Core - Contains could not be translated

I try to manipulate a CosmosDB (SQL) using entity framework core 3.0 (Microsoft.EntityFrameworkCore.Cosmos 3.0.0).
Everything works fine except when I try to use Contains, StartWith, …
For example:
var query = _context.Challenges.Where(c => c.Name.Contains( "string"));
EF is supposed to translate it to the following SQL (that works perfectly on the CosmosDB – Query Explorer)
SELECT * FROM c WHERE CONTAINS(c.Name, "string")
But I receive the following error message:
The LINQ expression 'Where<Challenge>(\n source: DbSet<Challenge>, \n predicate: (c) => c.Name.Contains(\"string\"))' could not be translated.
Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to either AsEnumerable(), AsAsyncEnumerable(), ToList(), or ToListAsync().
See https://go.microsoft.com/fwlink/?linkid=2101038 for more information.
Of course, I don’t want to code it like the following, that will execute the entire contains on the client, just to make a simple LIKE…
List<Challenge> entities = _context.Challenges.AsEnumerable().Where(c => c.Name.Contains( "string")).ToList();
Anyone has an idea of to evaluate the "contains" on the server side ?
Note: I try the exact same code using UseSqlServer rather than UseCosmos (and by adding the needed [Key] annotation and creating a SQL server) and it works like a charm.... So it's a definitively a CosmosDB vs EF issue.
By posting the same issue on entity framework core forum (https://github.com/aspnet/EntityFrameworkCore/), the answer was that this feature is not yet implemented:
https://github.com/aspnet/EntityFrameworkCore/issues/18673
https://github.com/aspnet/EntityFrameworkCore/issues/16143
https://github.com/aspnet/EntityFrameworkCore/issues/18451
https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6333414-implement-like-keyword

Rails 3 ActiveRecord::Relation random associations behavior

I am currently having a strange issue with an application migrated from rails 2.3.8 to rails 3 (3.0.1, 3.0.2, 3.0.3).
At random moments associations behave strangely. In some cases, an associated object will return the Relation object, instead of the corresponding model. This seems to happen mostly on polymorphic associations. For example:
class A
belongs_to :b, :polymorphic => true
end
class B
has_many :a, :as => :source
end
When invoking "a.b" this will "sometimes" return the Relation object (causing a "undefined method ... for ActiveRecord::Relation" error to raise) and some other times it will return the correct B object.
When the relation object is returned, it may sometimes be "fixed" temporarily by restarting the server, but it will eventually show up again.
Another issue i get is that when "getting" associated objects, sometimes the required filters are not automatically applied (where element id = ...). this causes the query to return the first object in the table and not the correct associated object.
This is becoming a very frustrating issue, specially since i don't seem to find anyone else with this or similar issues.
All finder methods in the application have been migrated to the new rails form, but this strange behavior remains.
The current configuration being used is:
Ubuntu 10
nginx server
passenger (3.0.2)
rails (3.0.3)
ruby 1.9.2p0 (2010-08-18 revision 29036)
After digging a bit deeper into the Active Record code, my co-worker and I found that the belongs_to_association.rb and belongs_to_polymorphic_association.rb were still using the old finder methods in the "find_target" method.
We ran a couple tests by logging the resulting objects of this method from different queries and discovered the old finders were returning the ActiveRecord::Relation at random moments (loading the same object it would sometimes return the object and other times the Relation object).
We overrode the find_target method for these 2 classes in initializer files, changing the finders used there to the new rails3 format (klass.select(...).where(...), etc). This seems to have solved the issue.
The "has_many" association files are already using the new format, so these haven't caused any issues.
We applied these "fixes" to the rails 3.0.3 and hope that they will be resolved in future releases.
Here are our initializer files in case someone else bumps into this problem:
belongs_to_polymorphic_association.rb:
#initializers/belongs_to_polymorphic_association.rb
module ActiveRecord
# = Active Record Belongs To Polymorphic Association
module Associations
class BelongsToPolymorphicAssociation < AssociationProxy #:nodoc:
private
def find_target
return nil if association_class.nil?
target =
if #reflection.options[:conditions]
association_class.select(#reflection.options[:select]).where(conditions).where(:id => #owner[#reflection.primary_key_name]).includes(#reflection.options[:include]).first
else
association_class.select(#reflection.options[:select]).where(:id => #owner[#reflection.primary_key_name]).includes(#reflection.options[:include]).first
end
set_inverse_instance(target, #owner)
target
end
end
end
end
belongs_to_association.rb:
#initializers/belongs_to_association.rb
module ActiveRecord
# = Active Record Belongs To Associations
module Associations
class BelongsToAssociation < AssociationProxy #:nodoc:
private
def find_target
key_column = (#reflection.options[:primary_key]) ? #reflection.options[:primary_key].to_sym : :id
options = #reflection.options.dup
(options.keys - [:select, :include, :readonly]).each do |key|
options.delete key
end
options[:conditions] = conditions
the_target= #reflection.klass.select(options[:select]).where(key_column => #owner[#reflection.primary_key_name]).where(options[:conditions]).includes(options[:include]).readonly(options[:readonly]).order(options[:order]).first if #owner[#reflection.primary_key_name]
set_inverse_instance(the_target, #owner)
the_target
end
end
end
end
Hope this is useful for someome
Thanks for sharing this. The problem with associations gone. But I still had this issue even with straight "find" method.
#post = Post.find(params[:id)
#post.update_attributes...
will fail with ActiveRecord::Relation error. However
#post = Post.find_by_id(params[:id])
#post.update_attributes...
will work
Seems like strange lazy loading behaviour

Resources