Skip to content
This repository has been archived by the owner on Jun 2, 2024. It is now read-only.

Feature Request: Include ID in results() array (optionally?) #24

Open
instanttim opened this issue Aug 15, 2018 · 6 comments
Open

Feature Request: Include ID in results() array (optionally?) #24

instanttim opened this issue Aug 15, 2018 · 6 comments
Labels
V1 - Feature Request Version 1 Feature Request

Comments

@instanttim
Copy link

When you use resultDocuments() you can get use getID() to get the ID. But when you use the lighter-weight and default results() there seems to be no way to also return the ID with the records in the array.

@instanttim instanttim changed the title Include ID in results() Feature Request: Include ID in results() array (optionally?) Aug 15, 2018
@timothymarois timothymarois added the V1 - Feature Request Version 1 Feature Request label Aug 15, 2018
@timothymarois
Copy link
Member

timothymarois commented Aug 16, 2018

To answer this one. You can call results() for both. results(true) (by default) will return just the data itself, meaning no way to have methods of calling ID. If you use results(false) this would give you all the documents and their methods. Which is the same as calling resultDocuments() But that's by preference. If you want the getId() then use resultDocuments() since all the document methods will be available. The reason ID is not inside the array of data is to prevent messing with any data you have stored on the document.

Unfortunately, there would be no way to use getId() with results() for just the array of data.

@instanttim
Copy link
Author

No, I get that... but why not an associative array where the keys are the IDs?

I would think it’s commonly desired to have the id available, but so much slower and resource intensive to have to iterate through the objects and gather the IDs and then flatten to an array and insert the the IDs.

Alternatively, I figured I could store the ID inside the document, but that seemed silly since the file name is already the ID. I guess that’s what I’ll do though for now.

@timothymarois
Copy link
Member

timothymarois commented Aug 16, 2018

@instanttim Actually, you do make a good point on the associative array keys. It would make sense to have the keys as document ids this way they can always be referenced. I'm going to add that to the list.

@timothymarois timothymarois reopened this Aug 16, 2018
timothymarois added a commit that referenced this issue Aug 17, 2018
…ange indexes from chronological integers to document Id. Adding the ID within the array key allows a reference the original document.
timothymarois added a commit that referenced this issue Aug 17, 2018
…nts() change indexes from chronological integers to document Id. Adding the ID within the array key allows a reference the original document."

This reverts commit 1e413bb.
@instanttim
Copy link
Author

Guess it didn't work?

@timothymarois
Copy link
Member

@instanttim It did, unfortunately, it didn't work with php 5.6, so I would need more testing into why the test failed. I currently am on a few other projects, the code is there if you want to take a look and see if anything stands out.

@chrissander
Copy link

chrissander commented May 16, 2019

I had the same problem, there is an easy workaround. Just store the id as a field in the itemdata right after you create the item, then it will be available in the results() array.

$item = $database->get('yourNewId');
$item->set(['id' => 'yourNewId']);
$item->save();

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
V1 - Feature Request Version 1 Feature Request
Projects
None yet
Development

No branches or pull requests

3 participants