mark Posted September 29, 2016 Report Share Posted September 29, 2016 Hi, So I tried session.get('TypedContext', entity_id) for an entity id that was a task. It worked...but then I tried it for other entity ids and they all return None. Any thoughts? Thanks! -Mark Link to comment Share on other sites More sharing options...
Mattias Lagergren Posted September 29, 2016 Report Share Posted September 29, 2016 Hi Mark, TypedContext works for task, milestone and other Objects that you can dynamically add and remove from System settings (like Shot, Sequence and so on). For other entities such as Note or AssetVersion you will need to use session.get('AssetVersion', version_id) or session.get('Note', note_id) Link to comment Share on other sites More sharing options...
Remus Avram Posted April 7, 2017 Report Share Posted April 7, 2017 On 9/29/2016 at 9:50 AM, Mattias Lagergren said: For other entities such as Note or AssetVersion you will need to use session.get('AssetVersion', version_id) or session.get('Note', note_id) Works with session.get('Note', note_id), but if I have only the id, not also the entity type, how can I get the entity? Link to comment Share on other sites More sharing options...
Mattias Lagergren Posted April 8, 2017 Report Share Posted April 8, 2017 On 07/04/2017 at 7:42 AM, Remus Avram said: Works with session.get('Note', note_id), but if I have only the id, not also the entity type, how can I get the entity? You only have the id and no information at all about the type of entity? There is no real good solution for that I'm afraid. Testing/Guessing is of course possible, but for performance reasons I would recommend that you try to keep identity of the entity and the entity type together. Link to comment Share on other sites More sharing options...
Remus Avram Posted April 12, 2017 Report Share Posted April 12, 2017 I see. Then I will all the time keep the identity of the entity and the entity type together. Link to comment Share on other sites More sharing options...
Remus Avram Posted April 12, 2017 Report Share Posted April 12, 2017 We are using session.get('TypedContext', entity['id']) in order to check if the entity still exists before committing changes. If we keep the entity type and id, then we suppose to check if the entity still exists if we run: session.get(entity.entity_type, entity['id']) Unfortunately, if the entity doesn't exists any longer, we get different results: session.get(entity.entity_type, entity['id']) Returns: <dynamic ftrack Task object 139839326832592> When: session.get('TypedContext', entity['id']) Returns: None In order to get it right, we must clean the cache all the time before: self._session.cache.clear() Link to comment Share on other sites More sharing options...
Nebukadhezer Posted April 12, 2017 Report Share Posted April 12, 2017 Are you also getting SYMBOL(NOT_SET) errors from session.get from time to time ?http://ftrack-python-api.rtd.ftrack.com/en/stable/api_reference/session.html#ftrack_api.session.Session.get this clearly states if the cache does not provide an answer then a query is issued... but I am often confronted with symbol(NOT_SET) instead... Link to comment Share on other sites More sharing options...
Remus Avram Posted April 12, 2017 Report Share Posted April 12, 2017 I got SYMBOL(NOT_SET) random when getting the custom attributes value without cleaning the cache. But I think that one is another story. session.get(entity.entity_type, entity['id']) is getting the data from the cache, which from my point, for scripts which run for long time, doesn't make sens because the cache is not updated. Link to comment Share on other sites More sharing options...
Nebukadhezer Posted April 12, 2017 Report Share Posted April 12, 2017 ok, I am having sessions that change their "auto_populate" value to "False" somehow... I cannot get my head around this, but setting it to "True" right before a get does do the trick. I just fell because I was using task.get("parent") and the pointer on task was not using my global session object but a copy of it, hence I had to set ```task.session.auto_populate = True``` Link to comment Share on other sites More sharing options...
Mattias Lagergren Posted April 12, 2017 Report Share Posted April 12, 2017 2 hours ago, Remus Avram said: In order to get it right, we must clean the cache all the time before: self._session.cache.clear() Yes, this is correct. It will still be in the memory cache if not cleared. Link to comment Share on other sites More sharing options...
Mattias Lagergren Posted April 12, 2017 Report Share Posted April 12, 2017 59 minutes ago, Nebukadhezer said: ok, I am having sessions that change their "auto_populate" value to "False" somehow... I cannot get my head around this, but setting it to "True" right before a get does do the trick. That sounds wrong, can you reproduce this behaviour some how? It would help us track down the bug if there is one. Link to comment Share on other sites More sharing options...
Remus Avram Posted April 12, 2017 Report Share Posted April 12, 2017 1 hour ago, Mattias Lagergren said: Yes, this is correct. It will still be in the memory cache if not cleared. ok, but then way this method query the DB and not using the cache? session.get('TypedContext', entity['id']) Link to comment Share on other sites More sharing options...
Mattias Lagergren Posted April 13, 2017 Report Share Posted April 13, 2017 21 hours ago, Remus Avram said: ok, but then way this method query the DB and not using the cache? session.get('TypedContext', entity['id']) Great input and I haven't thought about this before. The reason is that the identity of the object you get is a Task|Shot|Sequence|Folder|etc. and that is how it is cached. When you do the get on TypedContext the backend will figure out the correct subclass entity and return that. When the server request is done it will be merged into whatever exists in the memory cache. If you do this instead you will get it straight from the cache: session.get(entity.entity_type, entity['id']) Using get with TypedContext is good when you do not know the sub-class entity type. Link to comment Share on other sites More sharing options...
Remus Avram Posted April 13, 2017 Report Share Posted April 13, 2017 Thanks Mattias for the explanation! Link to comment Share on other sites More sharing options...
Remus Avram Posted April 20, 2017 Report Share Posted April 20, 2017 But is it possible to disable querying the cache and query all the time the DB when using session.get()? Link to comment Share on other sites More sharing options...
Mattias Lagergren Posted April 20, 2017 Report Share Posted April 20, 2017 No, I think in that case you should go for session.query as that will always query the server. It does however still merge it with the local cache. Link to comment Share on other sites More sharing options...
Remus Avram Posted June 28, 2017 Report Share Posted June 28, 2017 On 4/20/2017 at 7:21 PM, Mattias Lagergren said: No, I think in that case you should go for session.query as that will always query the server. It does however still merge it with the local cache. Unfortunately, session.query does not always query the server... Example: I create an assetBuild and a child task and in the same session, I query for the assetBuild and check for the children. Randomly, both session.get and session.query returns len(ftrack_asset['children']) = 0. Only after clearing the cache it returns the right data. (Pdb) len(ftrack_asset['children']) 0 (Pdb) ftrack_asset = self._session.get('TypedContext', ftrack_asset['id']) (Pdb) len(ftrack_asset['children']) 0 (Pdb) ftrack_asset = self._session.query("{0} where id is '{1}'".format(ftrack_asset.entity_type, ftrack_asset['id'])).one() (Pdb) len(ftrack_asset['children']) 0 (Pdb) self._session.cache.clear() (Pdb) ftrack_asset = self._session.get('TypedContext', ftrack_asset['id']) (Pdb) len(ftrack_asset['children']) 1 Is it possible to create an ftrack session without using the cache at all? Link to comment Share on other sites More sharing options...
Mattias Lagergren Posted June 29, 2017 Report Share Posted June 29, 2017 Hi Remus, For the query to fetch and refresh the children collection it is important to include it in the select statement: select children from Shot where id is "foo" Does it work for you then? Link to comment Share on other sites More sharing options...
Remus Avram Posted June 29, 2017 Report Share Posted June 29, 2017 Unfortunately, not really. In this case we need to remember all the time that we need to fetch the children as well. The same with clearing the cache as well. The best for us it would be if there would be a way to turn off the cache, like an argument for the session. Link to comment Share on other sites More sharing options...
Remus Avram Posted August 1, 2017 Report Share Posted August 1, 2017 On 4/8/2017 at 7:55 PM, Mattias Lagergren said: You only have the id and no information at all about the type of entity? There is no real good solution for that I'm afraid. Testing/Guessing is of course possible, but for performance reasons I would recommend that you try to keep identity of the entity and the entity type together. Keeping the id and the type of the entity together works for us pretty nice. But in the event hub, the event['data']['selection'] contains the id and the 'context_type' of the entity instead of the type of the entity. In this case we can't get nice the entity. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.