Is there a way to get the makeup (list of all segments ) of an index?
Thanks
-nat
No. There’s no API in SQLite to do it, so we wouldn’t be able to provide one. Why do you want to know?
We don’t have such an API in 2.0 . We have an API that returns the list of index names that were created so one option would be to give intuitive name to the index so you can identify the components.
@jens @priya.rajagopal
I want to give the end-user the power to create indices (and name them) themselves.
So, I want to check if an index definition like the new index end-user wants to create already exists.
-nat
ps. Of course this is not on the SERVER, just on the mobile device.
Oh, you want to see what indexes exist and what their properties are! I thought you wanted to see the list of keys/values in an index.
I want to check if an index definition like the new index end-user wants to create already exists.
Just try to create it, and see if you get an error.
This issue is not to important for me, but just for the record; when you create a new index, sqlite3 does no checking whatsoever, it first DROPS INDEX if exist, then merrily creates a new one. I want to side-step that overhead if possible.
Thanks.
nat
We use CREATE INDEX IF NOT EXIST.
Maybe you do so on .net but on Android you do exactly the opposite. Here is a log snippet: (log info directly from LiteCore)
I/LiteCore [SQL]: DROP INDEX IF EXISTS “Index_Test_1”
I/LiteCore [SQL]: DROP TABLE IF EXISTS “kv_default::Index_Test_1”
I/LiteCore [SQL]: CREATE INDEX “Index_Test_1” ON kv_default (fl_value(body, ‘PropDummy1’), fl_value(body, ‘PropDummy2’))
Please be aware that I am not advocating for it to be one way or the other. I AM saying that the dev should be in control of this, because either way is preferable in different scenarios.
The important thing is the behavior, not how we implement it. 
Have you confirmed it doesn’t do what you want? The API design for 2.0, for better or worse, was minimalist, not offering options we didn’t know of a need for.
Hey! That’s my line! I need not care how you implement expected behavior, nor why a certain behavior was implemented. Too many times we hear something like “yes but we had to do it this way because of reason x”.
As a dev I have learned to listen to end-users, and actually physically monitor end-users using my software for emotional [even ever so slight] reactions like ‘s__t’ or ‘wow!’ End-users don’t care why or how difficult it is for us to produce a specific behavior. Anyhow, I digress, sorry. Point is us devs are your end-users…
What do you mean? I posted the LiteCore log that says it is executing DROP INDEX?
Understood. But if many users mention an issue, than you now know there is a need for it. (Not to be taken as a complaint, but as an awareness and request for the next version.) For example, from my own experience and from many posts on the forum regarding a resultset NOT having the id unless specifically selected via Meta.id. This is UNEXPECTED behavior especially for a document db. Also, the extra steps required (overhead) to get a document from a Result. It is different and not natural. I am certain there is a solid technical reason (likely performance) as why you implemented the Result this way, but that does not mean it makes the dev happy. [Although most folks on this forum are much more polite than I am, and thank your team here for the extra hand-holding to achieve the required result, the very fact that the same topic comes up over and over, should trigger a flag for someone on cbl team that this [or any other implementation] is wrong and will be fixed in the next rev.]
Having said all that, I understand your point about 2.0 api design and the huge work involved in this massive re-write of the mobile client, and the need to get it out the door. I got that. At the same time though you need to acknowledge short comings and inform us if a requested feature or complaint will be addressed in a future version.
Simple idea (from other sites) that could save tons of typing for all of us, is to have some type of voting system. If any of us complains or requests a feature - no talking involved. Anyone can vote on it; [on this or related forum/media] up or down.
[not so polite]
-nat
That’s exactly what we are doing. If enough people say the same thing as you, that will be a trigger for us to consider things. We are taking notes internally on everything that gets requested.
Let me jump into the original issue here though. The API already allows index naming via the CreateIndex method (docs linked are for .NET arbitrarily because of my personal bias as the .NET developer, but this API is consistent). You can also check if a particular index exists by using the GetIndexes API and seeing if an index with your name exists already. I think the DROP INDEX is used for FTS indexes, while the CREATE IF EXISTS one is used for value based indexes, but I don’t remember precisely. This behavior won’t vary by platform because it is part of LiteCore, which is C++ code shared between the three languages.
Regarding the “know there is a need for it” we are definitely listening to everything that comes in and evaluating it. We aren’t just ignoring it, for sure. One person asking for it is not enough for us to put it in, at least not immediately, and we have a system for prioritizing requests for features (when I say “we” that actually doesn’t directly include myself. As a developer, I can influence and suggest what should go in but we have people who actually do not frequent these forums making the final decisions). The system takes input outside the forums as well. The “user voice” voting feature you suggested is a nice one too though, as it makes everything immediately apparent.
Here is the exact code that triggers a DROP INDEX:
db.createIndex("Index_Test_1",
IndexBuilder.valueIndex(ValueIndexItem.property("PropDummy1"),
ValueIndexItem.property("PropDummy2")));
As far as the other part of the general discussion/your post; most appreciated - thanks.
-nat
The behavior should be consistent between regular and FTS indexes (even if the SQL statements are different.)
I’m pretty sure we had some spirited debate about the behavior of creating an index that already exists (we had spirited debates about everything in the 2.0 API) but we settled on the current behavior. You can work around it by checking first to see if an index with that name already exists.