Hi @vince,
Thank you for looking into this!
The SQL query is above in the 9th post. 
Nadia
My bad I did not realised it was on a single line 
Okey so I’m not sure to follow. You said you did a migration so that ActiveStorage use uuid but clearly the primary key (id) of your active_storage_blob table is of type bigint 
.
Didn’t you miss a part in your migration ? Looking at that post it seems you forgot the migration of id to uuid
Hi @vince,
Something to keep in mind is that my app has been working perfectly fine in production, with a range of plugins/gems, etc., with over 150k users. It’s only with Forest that I’m having trouble! It’s not to say that there’s no chance that there’s some config I’ve neglected to update, but I suspect it’s something to do with Forest defaults. Hence why I keep asking about the auto-generated .forestadmin-schema.json file.
ActiveStorage uses two separate tables to store attachment information for other models. E.g. books have a reference to the active_storage_attachments table for their cover images and users have one for their profile picture.
The record_id column in active_storage_attachments expects a big_int by default. But in my app, I made books and users use UUIDs as their primary key. And so I needed to do a migration to change the record_id column within the active_storage_attachments table to expect type uuid as opposed to type big_int. For both the active_storage_blob and active_storage_attachments tables, their primary ID is of type big_int.
I think I really need somebody who’s familiar with Rails internals to help me. I’m still planning on digging in myself. But, I’m not doing anything too wild, so I’d be surprised if there’s nobody else using Forest who has a similar setup to me!
Okey so there is something weird cause its trying to join tables active_storage_attachments and active_storage_blobs on the record_id field but it should be on blob_id . I’ll try to see if I can find anything that could produce such an issue in our code base 
Thank you so much, @vince!
In the meantime, I’m going to try and set aside some time to investigate myself.
Hey @vince,
Back again and the same problem still remains!
Is there a way I can force Forest not to look at the record_id in this instance, but to look at the blob_id instead?
I’ve been playing around with the forestadmin-schema.json but no luck so far!
Thank you,
Nadia
Hello @Nadia,
Did you solve this issue and then it came back, or did you experience this problem all along since your first post?
It hasn’t been solved yet, or I definitely would have said!
I’ve been experiencing it all along unfortunately.
Hello @Nadia, I tried to figure out your issue, but it’s a bit complicated.
One piece of the puzzle seems missing though: can you share with us how relationships between your tables are declared in your app?
In the schema.rb that you shared, we can see the declaration of the different columns, but we cannot find there is no notion of foreign key here.
As far as I know about RoR, relationships are declared in models.
Also, can you dump the SQL declaration for the 2 tables for which you have issues?
For information, the file .forestadmin-schema.json is generated on startup from the information that RoR exposes through its internal structure. If something is wrong in this file, it indicates that the liana did not correctly detect the structure of your DB or model.
Thanks
Thank you for taking a look at this!
As previously mentioned, there are no model files for active_storage_attachments and active_storage_blobs since they are generated behind-the-scenes by Rails for its ActiveStorage library.
At the bottom of my db/schema.rb is the following though:
add_foreign_key "active_storage_attachments", "active_storage_blobs", column: "blob_id"
add_foreign_key "active_storage_variant_records", "active_storage_blobs", column: "blob_id"
And here is the SQL declaration for the two tables:
Table "public.active_storage_attachments"
Column | Type | Collation | Nullable | Default
---------------+-----------------------------+-----------+----------+--------------------------------------------------------
id | bigint | | not null | nextval('active_storage_attachments_id_seq'::regclass)
name | character varying | | not null |
record_type | character varying | | not null |
record_id_int | bigint | | |
blob_id | bigint | | not null |
created_at | timestamp without time zone | | not null |
record_id | uuid | | not null |
Indexes:
"active_storage_attachments_pkey" PRIMARY KEY, btree (id)
"index_active_storage_attachments_on_blob_id" btree (blob_id)
"index_active_storage_attachments_uniqueness" UNIQUE, btree (record_type, record_id, name, blob_id)
Foreign-key constraints:
"fk_rails_c3b3935057" FOREIGN KEY (blob_id) REFERENCES active_storage_blobs(id)
Table "public.active_storage_attachments"
Column | Type | Collation | Nullable | Default
---------------+-----------------------------+-----------+----------+--------------------------------------------------------
id | bigint | | not null | nextval('active_storage_attachments_id_seq'::regclass)
name | character varying | | not null |
record_type | character varying | | not null |
record_id_int | bigint | | |
blob_id | bigint | | not null |
created_at | timestamp without time zone | | not null |
record_id | uuid | | not null |
Indexes:
"active_storage_attachments_pkey" PRIMARY KEY, btree (id)
"index_active_storage_attachments_on_blob_id" btree (blob_id)
"index_active_storage_attachments_uniqueness" UNIQUE, btree (record_type, record_id, name, blob_id)
Foreign-key constraints:
"fk_rails_c3b3935057" FOREIGN KEY (blob_id) REFERENCES active_storage_blobs(id)
Hopefully this helps get to the bottom of the mystery! Thank you!
So, to wrap up, can you confirm these information:
-
active_storage_attachmentsandactive_storage_blobsare internal tables that are generated and managed by rails - you applied some migrations on these tables in order to change the primary key and foreign key types
- Forest Admin is still using the old foreign key when trying to join both tables
- You don’t have any definition of these models in your code
I found the model definition for these tables, and they are embedded in the code of rails itself:
I’m not sure of what is going on, but I know that this is not a good idea to change the structure of tables that are handled internally by Rails. As Forest Admin is using introspection on models, you have to be sure that your application uses models that are coherent with the DB structure. As you cannot modify the code that comes with Rails, your code should not apply migrations on these tables.
I don’t know if there is a way to adapt the model definition to use the right columns, but still, this is definitively not a good practice.
Yes, I had to change the primary key types to work with UUIDs, as specified within the Rails documentation here:
Since I’d already run the originally generated migrations, I had to do further migrations, which came out of the following discussion:
I’m running a decent-sized production app and using UUIDs instead of integers is a relatively common practice.
Keep in mind I can successfully use admin interfaces like Rails Admin and Active Admin — they just aren’t performant for a database of the size of mine.
I wish I could find somebody who used UUID primary keys, Active Storage, and Forest Admin. From then I’d be able to figure out where the configuration is going wrong.
1 Like
Hi Nadia,
Did you have find a solution for this problem?
I have this problem right now: UUID primary keys, Active Storage, and Forest Admin.
I’m always getting this error in everything related with the UUID primary keys and Active Storage.
“The request to your server either failed or returned invalid data. Please check your console logs to get more information.”
Thanks.
Hello!
If you’re talking about accessing the ActiveStorage tables, then no! In the end, I’ve kept them hidden and realised I don’t ever really need to access them via Forest.
If you do find a solution to this, please let me know!
Thanks for your reply Nadia.
The problem with my models is that they are related. For example, I have this simple model:
class Deposit < ApplicationRecord
has_one_attached :receipt_image
end
Because of it, I win these relationships:
- receipt image attachment
- receipt image blob
Because of these references, the problem also occurs. I put a lot of effort into trying to fix this issue today but for everything that I read around the web, it is looking like a Forest problem. I’m not having these problems with other tools like JetAdmin and other dashboards. It looks like it is a very old problem that has not been fixed.
1 Like
For information, the solution has been found and described here.