Hi Forest,
I recently added some new hasMany relationships to one of our tables. The issue is the related data tables are not displaying the records correctly. The number of records Forest fetched is correct, they are just displayed very strangely. I have shared two pages as well as the relationship declarations and project details. The project name is Monta. Thank you in advance! 
Hey @Arda_Yurdakul ,
Sorry I don’t understand what is your issue 
. What do you mean by displayed very strangely ?
Hey @vince
Sorry for not being that clear. Most of the data is not being displayed at all. In one of the pictures I sent above, Forest detects 273 entries but there are only 2 entries displayed per page(with only 19 pages). The number of entries fetched is accurate in the bottom but I can’t see almost any of the actual data on the table.
Here is another example from a different table in the same database. There are 1740 entries but we can’t see them. There is only a single entry per page:
Oh okey. So can you please go to the network tab and see how much records per page is requested ?
And could you also tell me if you have an error in your web console (I’m pretty sure you will have some 
) ?
Hey @vince
I’m sharing the query parameters. It seems the page size is 15. There are no errors in the console at all unfortunately. I have another piece of info that should be relevant. When I try to view this table by itself(not in related view of another table) I get the same entry in all rows. I hope this info is useful.
Hello @Arda_Yurdakul,
Thanks for your quick answer.
This issue looks pretty bad
Let’s focus on your Transactions list view issue first.
Do you know how many records are you supposed to have? Is it the correct number?
Do you always have the same record even when changing page?
Would you mind sharing with us the API response when fetching this list? Does it only this record on this response? Duplicated or not?
Thanks!
The correct number of records is only 77921. We can see here that the first entry appears 1746 times in the table. The two numbers multiplied approximately adds up to our 135 million so it’s safe to assume this is the case with all entries . Here is the json response beautified. The records are indeed duplicated here as well.
Thanks @Arda_Yurdakul.
Can you please share the model definition of ocppChargePointTransactions?
And can I ask you what exact version of forest-express-sequelize you’re using?
Thanks again @Arda_Yurdakul.
Would you mind upgrading your forest-express-sequelize to the latest version (8.2.7) and see if it corrects the situation?
And I guess you are entirely sure there is no duplicates in your database
Hey @anon34731316, .
I have just upgraded to 8.2.7 but the issue persists. I have double checked that there were no duplicates. Furthermore the duplicate entries all have the same id which is the primary key so it wouldn’t be possible to have these duplicates. Whenever I select one of these duplicates Forest selects all of them at once like so. I’m really at a loss as to what the problem is here.
This is insane… 
Ok, can you share your SQL table definition as well please?
Hey @anon34731316
I solved the issue but the exact cause still eludes me. I disabled all the model associations and the duplication issue was fixed. I later implemented all the associations as smart relationships and everything was fine. Understanding the root cause of the problem would be nice but at least it’s working normally. Thank you for the help 
@Arda_Yurdakul glad to hear you found a way out of this.
But we need to understand what went wrong with your associations in the first place!
Can you please tell me if you changed the associations definition, or if they were generated automatically by Forest in your forest admin backend?
And could you please also share the model definitions of your ocppChargePoints, ocppChargePointConnectors and ocppMeterSamples (with the associations definition)?
Thanks a lot.
Hey @anon34731316,
Sorry for the late reply, totally didn’t check the community tab since I was able to get around the issue 
I wrote the associations myself, as I do with all of our newer tables, I moved away from lumper update. The main difference in these associations was the foresign keys were not id fields. I simply assigned different source/target keys as you saw in the declaration, nothing fancy.
I’m sharing the model definitions below. Thank you for following up
