The way my models are set up:
an Order object has many RentalItems & TypeLogistics
RentalItem & TypeLogistic objects each has many ChargedAmounts & Refunds
further, the Order object itself has many ChargedAmounts & Refunds
The following queries appear to be working correctly, for when I want to eager load the stated associations for the 19th Order object in db:
# Load order, and its charged_amounts & refunds
#order = Order.includes(:charged_amounts, :refunds).find(19)
=>
Order Load (0.2ms) SELECT "orders".* FROM "orders" WHERE "orders"."id" = ? LIMIT 1 [["id", 19]]
ChargedAmount Load (0.3ms) SELECT "charged_amounts".* FROM "charged_amounts" WHERE "charged_amounts"."order_id" IN (19)
Refund Load (0.3ms) SELECT "refunds".* FROM "refunds" WHERE "refunds"."order_id" IN (19)
# Load order, its type_logistics, and the charged_amounts & refunds that belong to each type_logistic
#order = Order.includes(type_logistics:[:charged_amounts, :refunds]).find(19)
=>
Order Load (0.1ms) SELECT "orders".* FROM "orders" WHERE "orders"."id" = ? LIMIT 1 [["id", 19]]
TypeLogistic Load (1.1ms) SELECT "type_logistics".* FROM "type_logistics" WHERE "type_logistics"."order_id" IN (19)
ChargedAmount Load (0.3ms) SELECT "charged_amounts".* FROM "charged_amounts" WHERE "charged_amounts"."type_logistic_id" IN (26)
Refund Load (0.2ms) SELECT "refunds".* FROM "refunds" WHERE "refunds"."type_logistic_id" IN (26)
# Load order, its rental_items, and the charged_amounts & refunds that belong to each rental_item
#order = Order.includes(rental_items: [:charged_amounts, :refunds]).find(19)
=>
Order Load (0.3ms) SELECT "orders".* FROM "orders" WHERE "orders"."id" = ? LIMIT 1 [["id", 19]]
RentalItem Load (0.2ms) SELECT "rental_items".* FROM "rental_items" WHERE "rental_items"."order_id" IN (19)
ChargedAmount Load (0.2ms) SELECT "charged_amounts".* FROM "charged_amounts" WHERE "charged_amounts"."rental_item_id" IN (27, 28)
Refund Load (0.1ms) SELECT "refunds".* FROM "refunds" WHERE "refunds"."rental_item_id" IN (27, 28)
But the challenge is that I want to eager load ALL of it: the order's charged_amounts and refunds, and all of its rental_items and type_logistics and the charged_amounts and refunds for each rental_item and type_logistic.
But when I string the query together, it looks like the second set of associations (type_logistics and its charged_amounts and refunds) aren't loading at all based on the queries.
#order = Order.includes(:charged_amounts, :refunds, rental_items: [:charged_amounts, :refunds], type_logistics:[:charged_amounts, :refunds]).find(19)
=>
Order Load (0.2ms) SELECT "orders".* FROM "orders" WHERE "orders"."id" = ? LIMIT 1 [["id", 19]]
ChargedAmount Load (0.2ms) SELECT "charged_amounts".* FROM "charged_amounts" WHERE "charged_amounts"."order_id" IN (19)
Refund Load (0.2ms) SELECT "refunds".* FROM "refunds" WHERE "refunds"."order_id" IN (19)
RentalItem Load (0.2ms) SELECT "rental_items".* FROM "rental_items" WHERE "rental_items"."order_id" IN (19)
ChargedAmount Load (0.1ms) SELECT "charged_amounts".* FROM "charged_amounts" WHERE "charged_amounts"."rental_item_id" IN (27, 28)
Refund Load (0.1ms) SELECT "refunds".* FROM "refunds" WHERE "refunds"."rental_item_id" IN (27, 28)
But the charged_amounts and refunds on the order don't have any other associations, so they're not the "key" for anything. Any assistance here?
An approach I have followed in previous projects is:
Order.eager_load(:charged_amounts, :refunds)
.eager_load(rental_items: [:charged_amounts, :refunds])
.eager_load(type_logistics: [:charged_amounts, :refunds] )
.find(19)
I don't know if this may be the solution. Also note that I'm using the AR.eager_load method. Feel free to swap that for AR.includes
Related
I am going back to refresh my Rails knowledge by watching some tutorials, and I came across where the tutorial rails app uses includes() on index.
def index
#books = Book.all
end
vs
def index
#books = Book.includes(:author, :genre)
end
As a side note, book belongs_to author and genre. Author has_many books and genre also has_many books.
When all is used, it looks like this when I refresh page:
Rendering books/index.html.erb within layouts/application
Book Load (1.4ms) SELECT "books".* FROM "books"
Author Load (0.3ms) SELECT "authors".* FROM "authors" WHERE "authors"."id" = $1 LIMIT $2 [["id", 2], ["LIMIT", 1]]
Genre Load (0.3ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" = $1 LIMIT $2 [["id", 2], ["LIMIT", 1]]
Author Load (0.4ms) SELECT "authors".* FROM "authors" WHERE "authors"."id" = $1 LIMIT $2 [["id", 1], ["LIMIT", 1]]
Genre Load (0.3ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" = $1 LIMIT $2 [["id", 3], ["LIMIT", 1]]
CACHE (0.0ms) SELECT "authors".* FROM "authors" WHERE "authors"."id" = $1 LIMIT $2 [["id", 1], ["LIMIT", 1]]
CACHE (0.0ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" = $1 LIMIT $2 [["id", 3], ["LIMIT", 1]]
CACHE (0.0ms) SELECT "authors".* FROM "authors" WHERE "authors"."id" = $1 LIMIT $2 [["id", 1], ["LIMIT", 1]]
CACHE (0.0ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" = $1 LIMIT $2 [["id", 2], ["LIMIT", 1]]
When includes is used, when I reload the page it shows:
Rendering books/index.html.erb within layouts/application
Book Load (0.4ms) SELECT "books".* FROM "books"
Author Load (0.5ms) SELECT "authors".* FROM "authors" WHERE "authors"."id" IN (2, 1)
Genre Load (0.4ms) SELECT "genres".* FROM "genres" WHERE "genres"."id" IN (2, 3)
I think this makes includes far more efficient than all because it hits the entire model database.
My question is, why do people still use all? Why not completely eradicate all and use includes from now on? Is there any situation where I would prefer to use all and not use includes? I am using Rails 5.0.1.
Let me talk a little bit about includes.
Suppose you need to get the user name of first five post. You quickly write the query below and go enjoy your weekend.
posts = Post.limit(5)
posts.each do |post|
puts post.user.name
end
Good. But let's look at the queries
Post Load (0.5ms) SELECT `posts`.* FROM `posts` LIMIT 5
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 2 LIMIT 1
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 2 LIMIT 1
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1
1 query to fetch all posts and 1 query to fetch users for each post results in a total of 6 queries. Check out the solution below which does the same thing, just in 2 queries:
posts = Post.includes(:user).limit(5)
posts.each do |post|
puts post.user.name
end
#####
Post Load (0.3ms) SELECT `posts`.* FROM `posts` LIMIT 5
User Load (0.3ms) SELECT `users`.* FROM `users` WHERE `users`.`id` IN (1, 2)
There’s one little difference. Add includes(:posts) to your query, and problem solved. Quick, nice, and easy.
But don’t just add includes in your query without understanding it properly. Using includes with joins might result in cross-joins depending on the situation, and you don’t need that in most cases.
If you want to add conditions to your included models you’ll have to explicitly reference them. For example:
User.includes(:posts).where('posts.name = ?', 'example')
Will throw an error, but this will work:
User.includes(:posts).where('posts.name = ?', 'example').references(:posts)
Note that includes works with association names while references needs the actual table name.
Today I was attempting to set up caching using ActiveModelSerializers. I was having a lot of problems (my connection kept timing out). So I attempted to revert all my changes, including deleting the branch I was working on.
However, ever since I tried to set up caching, the model I was working with has exhibited strange behavior. It looks like it's still loading the cache elements. This is causing a huge performance hit when trying to access the endpoint for that model.
Started GET "/api/v1/entities" for ::1 at 2016-11-17 16:50:44 -0700
ActiveRecord::SchemaMigration Load (0.3ms) SELECT "schema_migrations".* FROM "schema_migrations"
Processing by Api::V1::EntitiesController#index as JSON
Entity Load (0.4ms) SELECT "entities".* FROM "entities" ORDER BY "entities"."name" ASC
Group Load (0.3ms) SELECT "groups".* FROM "groups" WHERE "groups"."id" IN (2, 3, 1) ORDER BY "groups"."name" ASC
Platform Load (0.4ms) SELECT "platforms".* FROM "platforms" WHERE "platforms"."id" IN (3, 8) ORDER BY "platforms"."name" ASC
HardwareType Load (19.3ms) SELECT "hardware_types".* FROM "hardware_types" WHERE "hardware_types"."id" IN (1, 3, 19, 8)
EntityType Load (0.2ms) SELECT "entity_types".* FROM "entity_types" WHERE "entity_types"."id" IN (1)
EntityOperationalState Load (0.4ms) SELECT "entity_operational_states".* FROM "entity_operational_states" WHERE "entity_operational_states"."entity_id" IN (1, 2, 3, 4)
OperationalState Load (0.2ms) SELECT "operational_states".* FROM "operational_states" WHERE "operational_states"."id" IN (1) ORDER BY "operational_states"."name" ASC
EntityLifecycleState Load (0.4ms) SELECT "entity_lifecycle_states".* FROM "entity_lifecycle_states" WHERE "entity_lifecycle_states"."entity_id" IN (1, 2, 3, 4)
LifecycleState Load (0.3ms) SELECT "lifecycle_states".* FROM "lifecycle_states" WHERE "lifecycle_states"."id" IN (2) ORDER BY "lifecycle_states"."name" ASC
IpAddress Load (0.3ms) SELECT "ip_addresses".* FROM "ip_addresses" WHERE "ip_addresses"."entity_id" IN (1, 2, 3, 4)
IpType Load (0.2ms) SELECT "ip_types".* FROM "ip_types" WHERE "ip_types"."id" IN (1)
IpUse Load (0.4ms) SELECT "ip_uses".* FROM "ip_uses" WHERE "ip_uses"."id" IN (1, 2)
[active_model_serializers] Entity Load (0.3ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 1]]
[active_model_serializers] CACHE (0.0ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 1]]
[active_model_serializers] Entity Load (0.2ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 2]]
[active_model_serializers] CACHE (0.0ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 2]]
[active_model_serializers] Entity Load (0.2ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 3]]
[active_model_serializers] CACHE (0.0ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" = ? ORDER BY "entities"."name" ASC LIMIT 1 [["id", 3]]
[active_model_serializers] Rendered ActiveModel::Serializer::CollectionSerializer with ActiveModelSerializers::Adapter::Json (71.13ms)
Completed 200 OK in 617ms (Views: 474.3ms | ActiveRecord: 27.8ms)
The [active_model_serializers] Load and CACHE are the new things that lead me to believe the serializer still attempting to load from cache.
My other models, which I didn't touch load with just one [active_model_serializers] statement, which is the behavior I expected.
Started GET "/api/v1/groups" for ::1 at 2016-11-17 16:56:15 -0700
Processing by Api::V1::GroupsController#index as JSON
Group Load (0.2ms) SELECT "groups".* FROM "groups" ORDER BY "groups"."name" ASC
Platform Load (0.3ms) SELECT "platforms".* FROM "platforms" WHERE "platforms"."id" IN (8, 3) ORDER BY "platforms"."name" ASC
GroupOperationalState Load (0.2ms) SELECT "group_operational_states".* FROM "group_operational_states" WHERE "group_operational_states"."group_id" IN (1, 2, 3)
OperationalState Load (0.2ms) SELECT "operational_states".* FROM "operational_states" WHERE "operational_states"."id" IN (1) ORDER BY "operational_states"."name" ASC
GroupLifecycleState Load (0.4ms) SELECT "group_lifecycle_states".* FROM "group_lifecycle_states" WHERE "group_lifecycle_states"."group_id" IN (1, 2, 3)
LifecycleState Load (0.2ms) SELECT "lifecycle_states".* FROM "lifecycle_states" WHERE "lifecycle_states"."id" IN (2) ORDER BY "lifecycle_states"."name" ASC
GroupConfigurationProfile Load (0.3ms) SELECT "group_configuration_profiles".* FROM "group_configuration_profiles" WHERE "group_configuration_profiles"."group_id" IN (1, 2, 3)
ConfigurationProfile Load (0.3ms) SELECT "configuration_profiles".* FROM "configuration_profiles" WHERE "configuration_profiles"."id" IN (1, 2, 3) ORDER BY "configuration_profiles"."name" ASC
[active_model_serializers] Rendered ActiveModel::Serializer::CollectionSerializer with ActiveModelSerializers::Adapter::Json (1.4ms)
Completed 200 OK in 51ms (Views: 36.3ms | ActiveRecord: 2.1ms)
Started GET "/api/v1/ip_addresses" for ::1 at 2016-11-17 16:58:34 -0700
Processing by Api::V1::IpAddressesController#index as JSON
IpAddress Load (0.2ms) SELECT "ip_addresses".* FROM "ip_addresses"
Entity Load (0.3ms) SELECT "entities".* FROM "entities" WHERE "entities"."id" IN (1, 2, 3) ORDER BY "entities"."name" ASC
IpUse Load (0.2ms) SELECT "ip_uses".* FROM "ip_uses" WHERE "ip_uses"."id" IN (1, 2)
IpType Load (0.1ms) SELECT "ip_types".* FROM "ip_types" WHERE "ip_types"."id" IN (1)
[active_model_serializers] Rendered ActiveModel::Serializer::CollectionSerializer with ActiveModelSerializers::Adapter::Json (2.85ms)
Completed 200 OK in 28ms (Views: 14.8ms | ActiveRecord: 0.9ms)
Those extra trips to the db are slowing down my load times, as you can see. These models all have around 3 objects right now, but when I was testing with many more records, this becomes a huge problem.
How can I force ActiveModelSerializer to either ignore the cached items?
A better option would be to figure out where those fragments were cached, so I can clear them out. I tried Rails.cache.clear, but this has no effect. I also tried, rebooting the computer, and also shutting down my Redis instance.
Never mind. Apparently this has nothing to do with the caching work I was doing.
I had a circular reference to the entity name in my has_many relationship
I'm trying to to cache a collection of items, this is my AMS:
class ApplicationCategorySerializer < ActiveModel::Serializer
cache({})
cache key: 'application_category', expires_in: 3.days
attributes :id
attributes :name
attributes :active
attributes :group
attributes :num_of_protocols
belongs_to :group do |serializer|
serializer.attributes[:group][:name]
end
def num_of_protocols
ApplicationCategory.find(object.id).protocol_categories.count
end
end
My problem is that without the :num_of_protocols part it takes 10 times faster to generate the response,
when I look at the log I can see:
Started GET "/application_categories.json" for 127.0.0.1 at 2016-08-04 19:12:27 +0300
Processing by ApplicationCategoriesController#index as JSON
ApplicationCategory Load (3.0ms) SELECT "application_categories".* FROM "application_categories"
[active_model_serializers] Group Load (1.0ms) SELECT "groups".* FROM "groups" WHERE "groups"."id" = ? LIMIT 1 [["id", 2066]]
[active_model_serializers] ApplicationCategory Load (0.0ms) SELECT "application_categories".* FROM "application_categories" WHERE "application_categories"."id" = ? LIMIT 1 [["id", 1]]
[active_model_serializers] (0.0ms) SELECT COUNT(*) FROM "protocol_categories" INNER JOIN "application_categories_protocol_categories" ON "protocol_categories"."id" = "application_categories_protocol_categories"."protocol_category_id" WHERE "application_categories_protocol_categories"."application_category_id" = ? [["application_category_id", 1]]
[active_model_serializers] CACHE (0.0ms) SELECT "groups".* FROM "groups" WHERE "groups"."id" = ? LIMIT 1 [["id", 2066]]
[active_model_serializers] ApplicationCategory Load (0.0ms) SELECT "application_categories".* FROM "application_categories" WHERE "application_categories"."id" = ? LIMIT 1 [["id", 2]]
[active_model_serializers] (0.0ms) SELECT COUNT(*) FROM "protocol_categories" INNER JOIN "application_categories_protocol_categories" ON "protocol_categories"."id" = "application_categories_protocol_categories"."protocol_category_id" WHERE "application_categories_protocol_categories"."application_category_id" = ? [["application_category_id", 2]]
[active_model_serializers] CACHE (0.0ms) SELECT "groups".* FROM "groups" WHERE "groups"."id" = ? LIMIT 1 [["id", 2066]]
...................... [many many more lines like those...]
[active_model_serializers] CACHE (0.0ms) SELECT "application_categories".* FROM "application_categories" WHERE "application_categories"."id" = ? LIMIT 1 [["id", 608]]
[active_model_serializers] CACHE (0.0ms) SELECT COUNT(*) FROM "protocol_categories" INNER JOIN "application_categories_protocol_categories" ON "protocol_categories"."id" = "application_categories_protocol_categories"."protocol_category_id" WHERE "application_categories_protocol_categories"."application_category_id" = ? [["application_category_id", 608]]
[active_model_serializers] CACHE (0.0ms) SELECT "application_categories".* FROM "application_categories" WHERE "application_categories"."id" = ? LIMIT 1 [["id", 609]]
[active_model_serializers] CACHE (0.0ms) SELECT COUNT(*) FROM "protocol_categories" INNER JOIN "application_categories_protocol_categories" ON "protocol_categories"."id" = "application_categories_protocol_categories"."protocol_category_id" WHERE "application_categories_protocol_categories"."application_category_id" = ? [["application_category_id", 609]]
[active_model_serializers] CACHE (0.0ms) SELECT "application_categories".* FROM "application_categories" WHERE "application_categories"."id" = ? LIMIT 1 [["id", 610]]
[active_model_serializers] CACHE (0.0ms) SELECT COUNT(*) FROM "protocol_categories" INNER JOIN "application_categories_protocol_categories" ON "protocol_categories"."id" = "application_categories_protocol_categories"."protocol_category_id" WHERE "application_categories_protocol_categories"."application_category_id" = ? [["application_category_id", 610]]
[active_model_serializers] Rendered ActiveModel::Serializer::CollectionSerializer with ActiveModelSerializers::Adapter::Attributes (1521.15ms)
how can I get better results with caching? - when I comment out the cache lines I get aprox. same times as with them, when I remove the :num_of_protocols I get same time with & without cache.
what am I configuring wrong?
Can you do this?
def num_of_protocols
object.protocol_categories.count
end
And, it's been a while for serializers for me, but I thought you were able to do this...
def num_of_protocols
protocol_categories.count
end
And this is better ruby (in the case protocal_categories is already loaded as an array)
def num_of_protocols
protocol_categories.size
end
And, if all that works or not, make sure you include protocol_categories and groups when you instantiate #application_category before you render to json. You're doing too many queries.
I'm a Rails and Ruby newcomer. I want to optimise SQL queries where I can and I was reading about using includes() to make Rails aware, that I want to eager load and join two tables.
In my show action on the pin controller:
def show
#pin = Pin.includes(:replies, :user).where(id: params[:id]).first
end
If I check the log on the queries, I see the following:
Started GET "/pin/1703704382" for 127.0.0.1 at 2014-06-12 15:30:18 +0100
Processing by PinsController#show as HTML
Parameters: {"id"=>"1703704382"}
Pin Load (0.2ms) SELECT `pins`.* FROM `pins` WHERE `pins`.`id` = 145 ORDER BY `pins`.`id` ASC LIMIT 1
Reply Load (0.1ms) SELECT `replies`.* FROM `replies` WHERE `replies`.`pin_id` IN (145)
User Load (0.1ms) SELECT `users`.* FROM `users` WHERE `users`.`id` IN (22)
User Load (0.1ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 22 LIMIT 1
Profile Load (0.1ms) SELECT `profiles`.* FROM `profiles` WHERE `profiles`.`user_id` = 22 ORDER BY `profiles`.`id` ASC LIMIT 1
CACHE (0.0ms) SELECT `profiles`.* FROM `profiles` WHERE `profiles`.`user_id` = 22 ORDER BY `profiles`.`id` ASC LIMIT 1 [["user_id", 22]]
Type Load (0.1ms) SELECT `types`.* FROM `types` WHERE `types`.`id` = 1 ORDER BY `types`.`id` ASC LIMIT 1
Skill Load (0.1ms) SELECT `skills`.* FROM `skills` WHERE `skills`.`id` = 3 ORDER BY `skills`.`id` ASC LIMIT 1
Instrument Load (0.2ms) SELECT `instruments`.* FROM `instruments` WHERE `instruments`.`id` = 6 ORDER BY `instruments`.`id` ASC LIMIT 1
Genre Load (0.1ms) SELECT `genres`.* FROM `genres` INNER JOIN `genre_pins` ON `genres`.`id` = `genre_pins`.`genre_id` WHERE `genre_pins`.`pin_id` = 145
Bookmark Load (0.1ms) SELECT `bookmarks`.* FROM `bookmarks` WHERE `bookmarks`.`pin_id` = 145
User Load (0.1ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 22 ORDER BY `users`.`id` ASC LIMIT 1
(0.2ms) SELECT COUNT(*) FROM `bookmarks` WHERE `bookmarks`.`pin_id` = 145
(0.1ms) SELECT COUNT(*) FROM `replies` WHERE `replies`.`pin_id` = 145
Rendered partials/_pin.html.erb (14.3ms)
Pin Load (0.1ms) SELECT `pins`.* FROM `pins` WHERE `pins`.`id` = 145 ORDER BY `pins`.`id` ASC LIMIT 1
CACHE (0.0ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = 22 ORDER BY `users`.`id` ASC LIMIT 1 [["id", 22]]
CACHE (0.0ms) SELECT `profiles`.* FROM `profiles` WHERE `profiles`.`user_id` = 22 ORDER BY `profiles`.`id` ASC LIMIT 1 [["user_id", 22]]
Rendered replies/_reply.html.erb (4.0ms)
Rendered replies/_form.html.erb (1.5ms)
Rendered pins/show.html.erb within layouts/application (21.7ms)
Rendered partials/_meta.html.erb (0.1ms)
Rendered partials/_top.html.erb (1.3ms)
Rendered partials/_tags.html.erb (0.1ms)
Rendered partials/_search.html.erb (1.0ms)
Completed 200 OK in 33ms (Views: 27.2ms | ActiveRecord: 2.0ms | Solr: 0.0ms)
It seems like it is running separate queries to get pins, replies and the user. How can I join these into one query? Surely this could be better optimised.
Thanks for your advice and patience!
It seems like it is running separate queries to get pins, replies and the user. How can I join these into one query? Surely this could be better optimised.
This is not automatically true. Hydration (the fact of creating nested records, etc, since you don't get in a hierarchical structure from your DB) can be very costly with many relations. It's actually often times better for your performance to use only a very simple query to fetch every record of one table.
If you still want to join (with shallow relations, it's probably better), you can use .joins
I finished few minutes ago my project. I made a commit, after this I wanted to clear DB because there was many testing records. So I ran this in my DBconsole:
sqlite> delete from users where id;
sqlite> delete from users where id=1;
sqlite> delete from posts where id=1;
sqlite> delete from votes where id=1;
After this my project didn't work(((. It returns:
We're sorry, but something went wrong.
If you are the application owner check the logs for more information.
On every page, even statics!!!!
I need my project to tomorrow. I restored from Git, but error is not disappeared.
My logs see like this:
Started GET "/" for 127.0.0.1 at 2014-03-14 04:08:40 +0200
Processing by PostsController#index as HTML
(0.4ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 1
(0.3ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 2
(0.4ms) SELECT COUNT(*) FROM "posts" WHERE ("posts"."statut" BETWEEN 3 AND 4)
Post Load (0.7ms) SELECT "posts".* FROM "posts" WHERE "posts"."statut" = 1 ORDER BY created_at DESC LIMIT 10
Post Load (0.6ms) SELECT "posts".* FROM "posts" WHERE "posts"."statut" = 2 ORDER BY created_at DESC LIMIT 10
Post Load (0.5ms) SELECT "posts".* FROM "posts" WHERE ("posts"."statut" BETWEEN 3 AND 4) ORDER BY created_at DESC LIMIT 10
Rendered posts/index.html.erb within layouts/application (23.5ms)
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 1
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 2
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE ("posts"."statut" BETWEEN 3 AND 4)
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 1
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 2
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE ("posts"."statut" BETWEEN 3 AND 4)
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 1
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 2
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE ("posts"."statut" BETWEEN 3 AND 4)
User Load (0.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id", 8]]
Completed 500 Internal Server Error in 74ms
This is for main page. Help me!! I can give u a git, I need to repair it, please.
You deleted all your users with this statement.
delete from users where id;
So the line in the log
User Load (0.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id", 8]]
Won't be able to load user with id 8 because the table is empty. Maybe you need to add back a user crucial for your program to function.