As I've been thinking about this I wouldn't do it based on last accessed
time, at least not directly. Using the example of moving infrequently used
blobs to cold storage, I would use a property on the node, e.g.
"archiveState=toArchive". In this case the property can be clearly tied to
that purpo
> From my perspective as an Oak user I would like to have control on that.
> It would be nice for Oak to make *suggestions* about moving things to
> cold storage, but there might be application constraints that need to
> be accounted for.
That sounds reasonable. What would be the "API" for this? L
On 29/06/2017 13:26, Thomas Mueller wrote:
> I'd like to backport OAK-5949 to the maintenance branches. It is a parsing
> error for XPath queries, so that the string literal '@' is not parsed
> correctly.
+1
On 29/06/2017 13:38, Thomas Mueller wrote:
> Hi,
>
> I'd like to backport OAK-6391 to the maintenance branches. The query result
> getSize() method is often used, and it is important that the result is as
> accurate as possible (even though the spec allows to return -1).
>
+1
On Fri, Jun 30, 2017 at 10:44 AM, Thomas Mueller
wrote:
> ...About deciding which binaries to move to the slow storage: It would be
> good if that's automatic...
>From my perspective as an Oak user I would like to have control on that.
It would be nice for Oak to make *suggestions* about moving
Hi,
I guess you talk about Amazon Glacier. Did you know about "Expedited
retrievals" by the way?
https://aws.amazon.com/about-aws/whats-new/2016/11/access-your-amazon-glacier-data-in-minutes-with-new-retrieval-options/
- it looks like it's more than just "slow" + "fast".
About deciding which b
Hi,
Right now, there is only one nodetype index. So, if you add a nodetype / mixin
to that index (as you know the lists of nodetypes / mixins is a multi-valued
property), then you need to reindex that index. Which needs to read all the
nodes.
The alternative would be to have multiple nodetype
