Baboo7 / strapi-plugin-import-export-entries

Import/Export data from and to your database in just few clicks.
179 stars 95 forks source link

[BUG] When Import nested Component #81

Closed ZiggyReQurv closed 1 year ago

ZiggyReQurv commented 1 year ago

Hi Baboo7, we are building a question manager with Strapi and we found a possible bug in the import process. We are currently using Strapi v4.5.1 and the last version of your plugin (v 1.18.0) and Postgres as DB. We've created a collection called Questions composed of two-level components, as shown in image1 Image1

When we create a new record in this collection, the result is image2

Image2

Our issue happened when we tried to export data from one DB and importing the exact same data to another DB (same version): what happen is that the result of the import looks like we have the same content as the previous image but when we make any changes in any record and then save, we have a duplication of the options component, as shown in image3. This does not happen in the question component, I imagine because in not a repeatable component. Image3

We made some digging in the DB and what we discover is that some data during the import process is not properly imported. The table shown in the image4 is called questions_components and contains the linking information between the Questions collection and its components. Image4

As you can see, the component_type column does not acquire the data of the component If you make any change in the record and then save (as described in image3), the data is duplicated as shown in image5, this time with the component_type properly set. Image5

After we found this behavior, we tried to import the same data to a new clean DB and immediately went to set the component_type column manually; we basically hardcoded the string we expected to find. The solution of inserting this data manually worked out, that's how we found out about the problem. In image 6 you can see what we hard-coded in the component_type. Image6

We then tried to make a change and save a record and the data was not duplicated, confirming our thoughts. After this edit, the records of the collection behave as expected. To be clear, the import DID NOT have any errors, the process went through with no errors. That's how we ended up thinking that during the import process the data of the component_type column is not set. This could be a limitation of the plugin when working with nested components. Let me know if you need any additional information. Thank you.

mitenka commented 1 year ago

Hey @ZiggyReQurv we faced the same issue and are trying to fix it now. By any chance have you had any success with this issue? Thank you

exploevo commented 1 year ago

HI @mitenka the developer never replies back to us so since we are using Postgres as a database we are starting to work directly from the database interface to export end import the date using the command: pg_dump --no-owner nomedatabase > filedumb.sql

psql databasericevente < filedump.sql

it was a pretty good turnaround that give us very good results and speed up our work. I hope that this could be useful to you Best wishes

mitenka commented 1 year ago

Hi @exploevo, thank you for sharing your experience! I guess the issue #91 is about the same thing. Thus I've created PR #97 to fix it. Hopefully it works for you as well. Feel free to report in case of any corner cases

Kyle772 commented 1 year ago

https://discord.com/channels/1021121498276171786/1021121949537153145/1049829680573849661

A user on the discord channel has figured out a work around until this is fixed

Here are the steps: 1) Run an import 2) Query through the db with pgadmin or another db management tool 3) Anything that ends in "_components" is a culprit 4) Look for component_type === null 5) Grab the value from the attributes."attribute_name".component key in each of your strapi schemas 6) do a bulk update on all component_types that are null and set it to the value from step 5 6.5) If you run into errors on placing values it's due to you already having duplicate entries in your db, I was safely able to just delete the duplicates (since the data is in the component_type null entries already). If you rerun a fresh import this can be avoided. 7) repeat through all "_component" tables 8) Backup your db once you've done them all so you have a checkpoint.

This took me about ~10 minutes to do on a pretty big strapi project.

mitenka commented 1 year ago

Thank you @Kyle772. Here's the SQL query (thank to ChatGPT) I used to find all corrupted records in all tables which names end with "_components":

DO $$
DECLARE
    v_table_name TEXT;
    v_column_name TEXT := 'component_type';
    v_record_count INTEGER;
BEGIN
    FOR v_table_name IN
        SELECT table_name
        FROM information_schema.tables
        WHERE table_schema = 'public'
          AND table_name LIKE '%_components'
          AND table_type = 'BASE TABLE'
    LOOP
        EXECUTE format('
            SELECT COUNT(*) FROM %I WHERE %I IS NULL
        ', v_table_name, v_column_name) INTO v_record_count;
        IF v_record_count > 0 THEN
            RAISE NOTICE 'Table % contains % records where % is NULL', v_table_name, v_record_count, v_column_name;
        END IF;
    END LOOP;
END $$;
Baboo7 commented 1 year ago

@Kyle772 @mitenka @exploevo @ZiggyReQurv this bug is fixed in version 1.19.0. Thank you @mitenka, your PR helped me a lot 🙏 😌