# Given the iid of something in the graph, how to retrieve it? **URL:** \ **Category:** TypeQL\ **Created:** [20 August 2024 22:18 UTC](https://forum.typedb.com/t/given-the-iid-of-something-in-the-graph-how-to-retrieve-it/558 "2024-08-20T22:18:04Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Jeff\_Brown](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.typedb.com/jeff_brown/32/138_2.png) [@Jeff\_Brown](https://forum.typedb.com/u/Jeff_Brown)\ **Post date:** [20 August 2024 22:18 UTC](https://forum.typedb.com/t/given-the-iid-of-something-in-the-graph-how-to-retrieve-it/558/1 "2024-08-20T22:18:04Z")
I recently asked, in the thread here: ```auto https://forum.typedb.com/t/how-to-get-the-unique-identifier-of-a-thing-in-the-graph/554/8 ``` “How to get the unique identifier of a thing in the graph?” Now I have the inverse question: Given the `iid` of something in the graph, how can you query to retrieve that thing? I understand that (although I don’t understand why) `iid` is not a normal attribute, and cannot be queried like the others. But `get` and `fetch` seem like the only methods remotely suited to the task. Both of the following queries (using the Python driver) elicit a `no viable alternative` error at the word `iid`. I imagine that means "No (ordinary) attribute called `iid` belongs to the class `person`. ```auto data_get ( db = DB_NAME, query = "match $p isa person, has iid '0x826e80018000000000000000'; get $p;" ) data_fetch ( db = DB_NAME, query = "match $p isa person, has iid '0x826e80018000000000000000'; fetch $p: iid;" ) ``` I’ve put the definitions of `data_get` and `data_fetch` at the end of this post. Aside from the list comprehension trick, they’re straight from the TypeDB QuickStart code. I’ve reread the documentation on `fetch`, `get`, and `concept`s. None of the `pattern`s seem relevant, nor do any of the `statement`s (`is` gave me hope, but no dice). And yet there must be a way to do this, right? If there isn’t, of course, I can just generate my own attribute, parallel to and unique like `iid`, but queriable in the ordinary way. But it would be embarrassingly inelegant. ```auto def data_fetch ( db : str, query : str ) -> ( Dict # Recursive JSON, whose type can't be specified # completely -- e.g. its depth depends on the query. ): with TypeDB.core_driver ( SERVER_ADDR ) as driver: with driver.session ( db, SessionType . DATA ) as session: with session.transaction ( TransactionType.READ ) as tx: return [ # The fetch object is an iterator # that becomes useless when the session ends. # This list comprehension # lets me smuggle the results outside the function. r for r in tx.query.fetch ( query ) ] def data_get ( db : str, query : str ) -> List [ # todo: Why are these `_ConceptMap`s, and how do # those differ from `ConceptMap`s (without "_")? _ConceptMap ]: with TypeDB.core_driver ( SERVER_ADDR ) as driver: with driver.session ( db, SessionType . DATA ) as session: with session.transaction ( TransactionType.READ ) as tx: return [ # The get object is an iterator # that becomes useless when the session ends. # This list comprehension # lets me smuggle the results outside the function. r for r in tx.query.get ( query ) ] ``` ---
**Author:** ![jameswhiteside](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.typedb.com/jameswhiteside/32/94_2.png) [@jameswhiteside](https://forum.typedb.com/u/jameswhiteside)\ **Post date:** [21 August 2024 09:14 UTC](https://forum.typedb.com/t/given-the-iid-of-something-in-the-graph-how-to-retrieve-it/558/2 "2024-08-21T09:14:36Z")
Hi, `iid` is a _constraint forming keyword_, similar to `isa` or `has`. This means that rather than treating it as a type label following `has`, as in your query above, you should instead use it in place of `has`: ```auto match $p iid 0x826e80018000000000000000; get $p; ``` A few other pointers: - You should not use `isa` and `iid` constraints on the same variable, as the `iid` constraint already contains the typing information. - IIDs should not be enclosed in quotes. - You can treat an `iid` constraint like any other constraint, and combine it with other constraints to form a pattern in the `match` clause, which can be followed by either a `get` or a `fetch` clause as needed. You should be aware that the `iid` keyword and the ability to retrieve IIDs are currently deprecated. Whether internal identifiers will be accessible in TypeDB 3.0 is still an open question, and it might take a very different form to the 2.x implementation. Correction: apparently it is possible to use `isa` and `iid` together to check if a given data instance is of a given type, but I’m not sure how this will behave. ---
**Author:** ![krishnan](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.typedb.com/krishnan/32/36_2.png) [@krishnan](https://forum.typedb.com/u/krishnan)\ **Post date:** [21 August 2024 12:17 UTC](https://forum.typedb.com/t/given-the-iid-of-something-in-the-graph-how-to-retrieve-it/558/3 "2024-08-21T12:17:28Z")
> it is possible to use `isa` and `iid` together to check if a given data instance is of a given type, but I’m not sure how this will behave. As always, It should behave as a conjunction of the `iid` constraint and the `isa` constraint. Which means the conjunction will fail if the instance isn’t of the specified type (or a subtype) ---
**Author:** ![Jeff\_Brown](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.typedb.com/jeff_brown/32/138_2.png) [@Jeff\_Brown](https://forum.typedb.com/u/Jeff_Brown)\ **Post date:** [21 August 2024 13:02 UTC](https://forum.typedb.com/t/given-the-iid-of-something-in-the-graph-how-to-retrieve-it/558/4 "2024-08-21T13:02:09Z")
Aha! Thanks. Is `iid` absent from the documentation ([TypeDB | Docs \> TypeQL \> Keywords](https://typedb.com/docs/typeql/keywords)) because you plan to remove it? Am I the only user you’re aware of who wants to be able to hold onto unique identifiers? I’m writing a note-taking app in TypeDB, where certain regions on the screen correpond to elements of the graph. Based on where the cursor is I want to be able to talk about the corresponding graph element with TypeDB – change its text, fetch objects in a certain kind of relationship with it, etc. If I lose the ability to access the iid I’ll definitely have to create a parallel one. I’m not complaining – like I said earlier, making a redundant field so I can access it is easy enough. But it’s hard for me to imagine I’m the only person who finds access to IIDs useful. ---
**Author:** ![jameswhiteside](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.typedb.com/jameswhiteside/32/94_2.png) [@jameswhiteside](https://forum.typedb.com/u/jameswhiteside)\ **Post date:** [21 August 2024 13:20 UTC](https://forum.typedb.com/t/given-the-iid-of-something-in-the-graph-how-to-retrieve-it/558/5 "2024-08-21T13:20:36Z")
IIDs are not currently static: they can be re-assigned as needed. This means that if you use an IID to identify a database object, the same IID will not necessarily refer to the same object next time you check. IIDs were not intended to be used as primary identifiers: they are literally “internal”, and should only be used in very specific ways. The same is true for equivalents in other databases, such as [Oracle’s ROWID](https://docs.oracle.com/cd/B19306_01/server.102/b14200/pseudocolumns008.htm). We decided to deprecate user-facing IIDs because they were being misused as primary identifiers, which could easily lead to problems when they are reassigned. This is also the reason that they aren’t currently documented. That said, IIDs will be static in TypeDB 3.0, and there are some thoughts about keeping them user-facing and making them easier to work with, as several users have indeed requested this. For now, I would recommend implementing your own system of IDs. ---
**Author:** ![Jeff\_Brown](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.typedb.com/jeff_brown/32/138_2.png) [@Jeff\_Brown](https://forum.typedb.com/u/Jeff_Brown)\ **Post date:** [21 August 2024 14:51 UTC](https://forum.typedb.com/t/given-the-iid-of-something-in-the-graph-how-to-retrieve-it/558/6 "2024-08-21T14:51:43Z")
Now I understand. Thanks, James!