Add/Remove labels

[jasperblues]

Would you consider expansion of scope to:

• Rather than expire, add or remove configurable labels, such as ActiveProfile, InactiveProfile
• Trigger from a configurable property, rather than expiration date. This property would take precedence over 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.

[ikwattro]

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 ?

[bachmanm]

+1, PR definitely welcome!

[jasperblues]

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:

• Don't already have the custom ExpiredNode label.
• Are qualified by the custom property (eg 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:

• Not already having the custom RevivedNode property.
• Being qualified by the custom property, expiration date or TTL.

Would something like that work for you?

[jasperblues]

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();
    }

[jasperblues]

Also, if wanted: IndexHits<Relationship> relationshipsExpiringBefore(long timestamp) could be strategy-specific, by delegating to the strategy.

[jasperblues]

Don't worry about the stuff above. I'll just send a PR and see what you think.

[jasperblues]

Closing this - discussion is on PR #9