I noticed similar log entries to this on our 7.0-3 cluster and I am
not sure if it is anything to be concerned with-
2014-07-28 00:23:00.812 Debug: Forest::insert: Meters
XDMP-INMTRPLIDXFULL: In-memory triple-index storage full; list:
table=2%, wordsused=2%, wordsfree=97%, overhead=1%; tree:
Hi Harry,
MarkLogics built-in history logging (the Meters database) is using triples. So,
nothing to immediately worry about. It might affect monitoring though. I'd have
to check what could be behind this..
Cheers,
Geert
Van: general-boun...@developer.marklogic.com
This is a Debug level log so that itself is an indication that this is not an
issue but or even generally 'informative' for normal use (or it would be a
warning or higher).
Its due to the metering collection and its indicating that enough memory was
used to that the in memory
Index was flushed
I am in the early design stages of a (hopefully) large application and
would like to see if I understand the operations of collections correctly.
You can think of this in a similar context to a social media app.
I have attached a simple diagram to aid the text.
Imagine that Joe, Sue and Tom are
Hi All
I’m working on an xslt transform where I’m extracting data about images from a
document and put
that data into result document, It all works fine except for when the same
image occurs more than once as I then get conflicting uris,
my code looks like this
xsl:template
I think you may be running afoul of URI resolution.
Since the URI you are giving to doc-available is a relative
URI, it will be resolved relative to the static base URI, which
per XSLT is the URI of the stylesheet itself.
//Mary
On Mon, 28 Jul 2014 07:58:04 -0700, Erik Zander
I believe you should be able to do something like the following to get what
you want:
xsl:template match=//db:informalfigure[descendant::db:imagedata and
@role='figure']
xsl:variable name=curImage select=
substring-after(.//@fileref,'/')/
xsl:variable name=id select=
Hi Tim,
I am not sure I have thought this through completely, nor can I think of the
exact steps to do this, but here is my instinct on how I would attempt to solve
this:
I would try to create amped functions that allow Sue to share (read only) Tom’s
document (that Sue has read permission
In the builtin security model, simply adding a collection to a document won't
make that document visible to another user. Visibility of documents is
controlled by read permissions and roles. Granting read permission for a
document to a role makes that document visible to users that have that
Thanks Danny. I was hoping to get a discussion around this because I am
not sure it is as simple as I first thought.
I had not considered using amped functions to do it.
Of course this was just a three person example. The real use case involves
Sue needing to have the ability to share read
For your question about collections, there are 2 types of collections,
“collections” and “protected collections”. Collections have no security
associated with them, and a document can have many (or no) collections, but
access to the document is simply by permissions.
Protected collections are
Awesome, thanks.
On Jul 28, 2014 5:06 AM, David Lee david@marklogic.com wrote:
This is a Debug level log so that itself is an indication that this is
not an issue but or even generally 'informative' for normal use (or it
would be a warning or higher).
Its due to the metering collection
12 matches
Mail list logo
