Closed jasperblues closed 7 years ago
I think both requests are perfectly valid and would love to see such PR.
Just a question, regarding the labels, what should a node without any of the labels be considered as ?
+1, PR definitely welcome!
Btw, I wanted to also add a configuration to the indexer to only apply to nodes with a configurable set of labels. For example to CandidateProfile
nodes.
Just a question, regarding the labels, what should a node without any of the labels be considered as?
I have a use-case where I would like the indexer to apply either the expired label and remove the revived label or vice-versa. Being able to query both sub-graphs is useful.
Therefore, would it work to have the indexer handle revival as well? I would introduce a new ApplyLabels
strategy that depends on this.
Some Concerns
Currently relationshipsExpiringBefore
almost always returns a reasonably sized set that can be actioned in doSomeWork
. For the cases when its not, eg on startup, its protected by getMaxNoExpirations
. To ensure this remains the case, the method will return nodes that:
ExpiredNode
label. lastActive
), expiration date or TTL. Having the indexer handle revival as well means that doSomeWork
relies on a new indexer method nodesRevivingBefore
. They'll be kept to a manageable set by:
RevivedNode
property. Would something like that work for you?
For optimization, each strategy could have two new properties: expires
and revives
, so that needless work isn't done. The existing strategies, that do deletion, would have revives
return false.
public TimerDrivenModuleContext doSomeWork(TimerDrivenModuleContext timerDrivenModuleContext, GraphDatabaseService graphDatabaseService) {
long now = System.currentTimeMillis();
int expired = 0;
if (strategy.expires()) {
//perform expiration
}
if (strategy.revives() {
//perform revival
}
return new EmptyContext();
}
Also, if wanted: IndexHits<Relationship> relationshipsExpiringBefore(long timestamp)
could be strategy-specific, by delegating to the strategy.
Don't worry about the stuff above. I'll just send a PR and see what you think.
Closing this - discussion is on PR #9
Would you consider expansion of scope to:
ActiveProfile
,InactiveProfile
expirationDate
and TTL.Would you accept a PR for such a feature? No worries if the above is beyond the scope of this module. Wanted to check to avoid doubling up.