| 55 | However this is a naive solution and fails in practice because there are both stored and non-stored fields. Using this strategy will lose the non-stored fields. |
| 56 | |
| 57 | A potential solution comes to mind: |
| 58 | |
| 59 | * Create 2 documents from metadata xml |
| 60 | * a document only containing fields with stored data |
| 61 | * a document containing fields only with non-stored data |
| 62 | * Insert both documents into index |
| 63 | |
| 64 | Now the document with stored fields can be updated without losing any data. |
| 65 | |
| 66 | Obviously this impacts how searching is done. First it means that searches that involve both stored and non-stored fields need to be split and recombined. |
| 67 | |
| 68 | For example &(any:water title:salt) |
| 69 | |
| 70 | if title is stored and any is not then two searches have to be combined and documents that are in both searches (based on metadata id) are the true results. Ordering of results will be very difficult. |