-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Attempt to load value of nonexistent EAV attribute #598
Comments
@craigcarnell - Same here with CE 2.2.6, investigating... |
Hi @craigcarnell Thank you for reporting the issue. Internal ticket MAGETWO-95789 to investigate and fix it |
Same issue with Magento Open Source 2.2.6 with migrated data. |
@victor-v-rad any update on this issue? |
Not yet. Does it create any issues apart from the warning message in system.log file? |
@victor-v-rad no just system.log writes |
This issue is created on the M1 side. When in M1 > admin panel > some product has value set for its custom attribute and you remove this attribute from attribute group, then M1 do not clean the value you set for the product. It should remove record from from catalog_product_entity_int) |
@victor-v-rad In M1 DB I have run: https://gist.github.com/dfelton/042e15a51b9795b25cad0235a1bf9122#file-magento-ee-1-14-2-0-sql I have then created a new DB. However, I still get the following:
Is there any other SQL I need to run? |
I do not have this SQL. The issue will be fixed in according ticket |
In my m2 DB: I've checked eav_attribute for 83 which is color. This is some clean up SQL that I found:
Is this correct? I do however, get this error message when a eav_attribute is still in a set. For example, eav attribute 395 is in 7 attribute sets but it still included in the error message.
|
@craigcarnell Color has Dropdown input type, hence its values stores in catalog_product_entity_int. But there are many other attributes with other input types, which can store their values in catalog_product_entity_varchar, catalog_product_entity_text, catalog_product_entity_decimal, etc. |
@victor-v-rad Is it safe to delete this data in this case, for example - color where the data is not used? |
In M2 if you unassign some attribute from an attribute group the values in catalog_product_entity_* tables are cleaned up accordingly. So it should be safe to delete it by SQL query. One more way to delete these values is in Admin Panel assign and unassign these problematic attributes from existing attribute group and Magento should clean catalog_product_entity_* tables |
I hope this is useful to somebody, but this is what I'm using on M1:
|
The above SQL worked for me, going to close this ticket for now. |
Re opened as my sql didn't fix everything it would seem |
Just to add -- I started noticing this when I just upgraded to 2.2.6 and my system.log and support_report.log started growing exponentially. Each log file was 7GB within 12 hours of a logrotate. Is it possible the upgrade to 2.2.6 added a bunch of unnecessary data? |
These seem to regenerate after moving a product to a new attribute set in the admin. So, that would indicate that Magento isn't cleaning up after itself either, removing orphan values when no longer part of the current attribute set. This appears to create a considerable slowdown in the process of saving products. Cleaning the orphans results in an increase in admin speed. |
@victor-v-rad Any updates on this issue? |
We are having the issue on Magento Open Source 2.2.7 as well. |
Same with 2.3.0. |
Same 2.3.0 |
@JamesAllwood in what way are you cleaning the orphan values? |
Hi all, This is what I'm using on M2. It's very similar to the above on M1. I'm not sure why it is required, as this data has already been "cleansed" in M1 before migration? I have not edited or changed anything in M2 post migration with this one. Do not try this on live..
|
@snoroozi yes, I have a few queries that do the trick for me. Use at your own risk, and it goes without saying, only use if you have a backup available (also, don't judge me on the sql, I'm sure there's better ways to have written it). These handle values from products and categories, as I found issues there too:
|
@JamesAllwood Thanks for sharing. Have you noticed any ill effects from doing these? Usually you fix one thing you break another you know? @victor-v-rad do you have any update on official magento fixes for this issue? |
Hi @snoroozi |
My main job is as a merchant pseudo-developer sysadmin. So don't think I'll
be much help.
…On Thu, Mar 7, 2019 at 10:48 AM Victor Rad ***@***.***> wrote:
Hi @snoroozi <https://github.com/snoroozi>
Not yet, but the tool is open for your contribution
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#598 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACQbJaVUPgi6LuAem7BsLJGy2t8SoF6uks5vUTS1gaJpZM4XKKjk>
.
|
Magento 2.3.0 CE -> Have you checked if the attribute in question has been added to the product attribute_set list? |
this is a post migration problem |
just try to check hidden files with . prefix owner to be magento owner, it worked for me since the upgrade process will reset everything to default |
@emadof85 who are you replying to and what are you talking about exactly? |
i am having same issue in Magento 2.2.6, is there any solution exist ? |
same with magento 2.2.7 |
same with magento 2.2.8 |
I would like to mention that I'm facing the same issue. I've migrated from 1.7 though but the issue is the same and is happening in not only products but categories as well. This issue does have a performance impact when saving products or categories when throwing these warnings. Instead of taking very little time to save, it takes significant more time while looking up missing attributes. |
Is there any well proven solution to this problem? |
In M 2.2.8 the issue is caused by the way the Magento\Eav\Model\ResourceModel\ReadHandler is populating eav_entities. The log message is misleading. For the sake of simplicity I will talk about the product entity. The ReadHandler loads all the attribute codes and ids associated with the entity based on the corresponding attribute set.
It then loads all the values from all value tables(catalog_product_entity_varchar|int|etc). Each time an attribute value is found that does not have a corespondent in the $attributesMap it logs this message.
Each time a there is a value on an entity in one of the value tables, that is not in the current used attribute set on that entity, this message will be logged. There are a couple of options, I'll present two. Both should be approached carefully.
As is, I don't think this is a data_migration_tool (just an opinion) but rather a bizarre way of populating eav entities. The log message is wrong 100% as the attribute might very well exist. I'm pretty sure this logic was not in all 2.2.x versions as I only started seeing the logs after I upgraded from 2.2.3 -> 2.2.8. |
This is more pertinent to my situation since I only ever upgraded from 2.1.8 to 2.2.6; and referenced attributes in the log do exist so the warning was very confusing for me. For me it references the same attributes constantly (114 - country_of_manufacture & 184 - a custom one I created). It looks like there was attention given to this issue on GitHub for ReadHandler.php: |
…which is not included into attribute group #598
Fixed in c5d7b65 |
@victor-v-rad Thanks 👍 Now migrated onto m2. Not seeing this after running the SQL I mentioned above on M1 followed by M2 cleanup. Feel free to re-open if anyone else needs it. |
…en product is assigned to root category #598
Preconditions
Steps to reproduce
Expected result
Actual result
attribute_id entity_type_id attribute_code attribute_model backend_model backend_type backend_table frontend_model frontend_input frontend_label frontend_class source_model is_required is_user_defined default_value is_unique note
83 4 color [NULL] [NULL] int [NULL] [NULL] select Color [NULL] [NULL] 0 1 [NULL] 0 [NULL]
The text was updated successfully, but these errors were encountered: