Skip to content
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

Handling duplicate entries with the same parent ID #43

Open
GaryJones opened this issue Feb 10, 2014 · 3 comments
Open

Handling duplicate entries with the same parent ID #43

GaryJones opened this issue Feb 10, 2014 · 3 comments
Labels

Comments

@GaryJones
Copy link
Member

When the same hook is called twice within the same function, the check for an existing ID will come up as true, even though the meta (e.g. line-number) will likely be different for the second call as the first call. Equally, if functions with the same name are defined twice, perhaps in the global namespace (parent ID = 0) in different files that are not included within the same request, they too will have different meta data and should be different entries.

Perhaps a join to postmeta table on the existing ID check and also compare the file and / or line number would narrow it down?

If the same hook is being called twice on the same line in the same file, well, that's just stupid! (But technically plausible.)

@JDGrimes
Copy link
Contributor

JDGrimes commented Apr 7, 2014

Comparing the line number won't work as a solution here. When the source is updated the line numbers are bound to change. When that happens we won't know which hook call belongs to which database entry, so we'll end up creating duplicates. Storing the line numbers as an array with an entry for each call to the hook might be a better solution.

@DrewAPicture
Copy link
Member

Storing the line numbers as an array with an entry for each call to the hook might be a better solution.

Or just not storing the line numbers at all. That is, unless you guys are personally volunteering to maintain them. I think we're going to need a better way.

@JDGrimes
Copy link
Contributor

JDGrimes commented Apr 8, 2014

Or just not storing the line numbers at all. That is, unless you guys are personally volunteering to maintain them. I think we're going to need a better way

The parser is going to be maintaining the line numbers. We need to store them so that we can link to the source, or even display it directly. The parser will store/update the line numbers when importing. But the issue is how can the parser figure out which set of line numbers belongs to which instance in the source when updating/re-importing? Which line numbers does it need to update?

The way the parser works now, it doesn't know if there are multiple instances of a hook at all. It can't easily tell that from the exported data, and I think maybe that is the problem. Maybe we should change the exporter so that when it encounters a hook twice in the same parent structure, it won't export a second entry for that hook, but instead just add a second set of line numbers for it.

So I think that this should probably be handled on the exporter level, rather than by checking the database on import.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants