The phone's index

One index per phone, named after the phone, created only when it is certainly missing.

Every phone gets one Opensolr Index of its own, in your account. The app finds it, creates it or creates it again — and only ever creates one when it is certain it is missing.

Sync starts forced or scheduled Is this phone's index in the account? photos_<ANDROID_ID>__dense yes no Reuse it Schema missing? upload it. Read address and password. Create it Pick a vector environment, create, upload the config. Re-Sync Only the differences: add new, delete gone. Full sync Known photos come back from the phone's cache. Created again after it vanished? The user is told the index was emptied and is being refilled. A network error, a server error or a refused key never creates anything: the next sync tries again.

Figure 1 — what every sync does with the phone's index.

01 · The name

The index is named photos_<ANDROID_ID>__dense. ANDROID_ID is the identifier Android gives this app on this phone: it stays the same when the app is reinstalled, and it is different on every other phone.

Reinstall on the same phone

Sign in, and the app finds the index by its name. It only runs a Re-Sync, which adds and deletes the differences.

A new phone, same account

A different ANDROID_ID, so a different name: the new phone gets an index of its own.

02 · Reusing it

When the name is in the account's index list, the app reads the index's address and password from the account and checks that the index carries the app's current configuration: the newest field of the schema must exist and the autocomplete handler must answer. An index on an older configuration gets the new one uploaded, and every photo is then written again from the phone's cache, without AI requests, so the new fields are filled in; the photo grid says Index update in progress meanwhile and search keeps working. Then the sync goes on as a Re-Sync.

03 · Creating it
  1. Pick the nearest environment. If you allowed the app to read the phone's coarse position, a phone in the Americas gets its index on Opensolr's Chicago environment and every other phone on the Finland environment; without a position, the phone's time zone decides the same way. The position is read once, on the phone, and never sent anywhere. Should the chosen environment not be offered, the newest one that runs vector search on the same continent is used.
  2. Create the index with that name in that environment.
  3. Upload the configuration that ships inside the app: schema.xml, solrconfig.xml and the analyzer files.
  4. Wait until it answers with the new schema. Right after a create the index needs a few seconds to reload and apply its password and firewall rule; the app waits that out instead of mistaking it for an error.
04 · When it vanished

If the phone had an index and it is no longer in the account — deleted from the control panel, removed as unused, anything — it is created again the same way, and a notification says the index was emptied and is being filled again. The fill comes from the phone's cache, without AI requests for photos read before.

The one rule that prevents stray indexes

An index is only created after the account's index list was read successfully and did not contain it. A network error, a server error or a refused key never lead to a create: they end the run, and the next sync simply tries again.

05 · Looking at it yourself

It is a regular Opensolr Index. Open it from the app's account screen or from the control panel to query it, back it up or empty it. Emptying it is safe: the next sync fills it again.

Opensolr Photos is open source and MIT licensed. Questions about your Opensolr account, index or plan go to opensolr.com/contact; questions about the app itself belong on GitHub.

Opensolr Photos Documentation