falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Balu Vellanki <bvella...@hortonworks.com>
Subject Discuss : Handling entity deletion in Falcon
Date Wed, 05 Aug 2015 21:43:46 GMT
Hi Team,

Question 1:
As of today - Entities and their successful instances are stored in GraphDB. Entities are
stored in configuration store. When an entity is deleted, the deleted entity is archived under
configuration store. There is no way to list deleted entities via an existing API. The entities+instances
are not deleted from GraphDB.   So when an entity is deleted, should Falcon keep entity+instances
for historical purposes or should Falcon delete them from graphDB? Should Falcon have an API
to list archived entities?

The potential use case here is that a user might want to see the instances of deleted entities
(jobs) for historical/bookkeeping purposes. Please discuss if this is a valid use case that
Falcon should support. If yes,  Ying Zheng and Venkat Ranganathan suggested that Falcon should
create a disk based archival store that can be queried. Since it is disk based, it will be
slow. But the user understands that limitation, and the frequency of bookkeeping requests
should be lot fewer than regular APIs.
If you think this use case should not be supported by Falcon, the simple solution is to delete
the entity+instances from the graphDB.

Question 2 : When entity is deleted and a new entity is created with same name,  Is this equivalent
to update of an entity OR is the new object considered an entirely different entity?

I believe the new entity should be treated as a different object, and the deleted entity of
same name plus it's instances should not be associated with new entity. If falcon does not
treat the entities as different objects, Falcon will have to introduce versioning of entities.
 All instances of an entity should be associated with a specific version of entity. Personally
- I do not see a strong use case today for versioning.

Please discuss.

Thank you
Balu Vellanki

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message