pack the code a bit.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
>
uot;.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
> Issue Type:
uest:
https://github.com/apache/jena/pull/94#issuecomment-154127004
Weird. I don't know what that means, but it certainly doesn't seem right.
Several of the intermediate commits in that last also came well after 19 July
(which is what it says on my page!).
> Develop a
uest:
https://github.com/apache/jena/pull/94#issuecomment-154126125
meta observation: Github says "added some commits on 20 Jul". This is not
the whole story because 037fd1a, for example, is today (5 Nov).
> Develop a new in-memory RDF Datas
diff --
Huge amount of change for adding/changing a couple of operations.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/j
fiable Dataset
+*/
+ public static Dataset createGeneral() {
+ return createTxnMem();
+ }
+
--- End diff --
This should go to the used to be `createMem()` i.e.
`create(DatasetGraphFactory.createMem()) ;`.
> Develop a new in-memory RDF Dataset implementation
&g
return new DatasetImpl(model);
--- End diff --
Why adding al the `final`? The compiler, with "effectively final", does
this anyway.
Adding `final` to arguments just increases the syntax line no
return quadsIndex().find(ANY, s, p, o).filter(q ->
!q.isDefaultGraph() && seen.add(q.asTriple()))
+ .iterator();
+ }
--- End diff --
Is the q.isDefaultGraph needed? Aren't default graph triples
duplicates come out adjacent don't they? Hence only need to do
an adjacency test.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issue
return quadsIndex().find(ANY, s, p, o).filter(q ->
!q.isDefaultGraph() && seen.add(q.asTriple()))
+ .iterator();
+ }
--- End diff --
I don't see any tests for the union graph.
> Develop a new in-memory RDF Dataset
traversed is SPOG, then duplicate graph names are adjacent
which is much cheaper than distinct.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jir
, isn't the top level of any index starting with a G
enough to get all the graph names? The key set of the FourTupleMap for GSPO is
enough, much faster, no retention of state needed for `distinct()`.
> Develop a new in-m
fiable Dataset
+*/
+ public static Dataset createGeneral() {
+ return createTxnMem();
+ }
+
--- End diff --
Ah, right. Will fix.
> Develop a new in-memory RDF Dataset implementation
> --
>
>
aph was in the same structures as named graphs. I'll fix that.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
>
return quadsIndex().find(ANY, s, p, o).filter(q ->
!q.isDefaultGraph() && seen.add(q.asTriple()))
+ .iterator();
+ }
--- End diff --
I'll get some t
e`s, which may happen (do, in the default case) to be implemented
with maps, but could just as well be implemented with some other technique that
wouldn't produce adjacency as an artifact. (E.g. @Claudenw 's idea about Bloom
fi
DatasetGraphInMemory` as to union graph functionality.
It applies here too. This is an interface which has no reason or right to
assume anything about adjacency.
> Develop a new in-memory RDF Dataset implementation
> --
>
G, that's why this is a `default` method. Look at
`HexTable` and you will see that very advantage being taken. But this is a
`default` method and must not rely on facts about an implementation.
> Develop a new in-m
only a small windows of results (e.g current and previous), the
there is no state accumulation.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apa
End diff --
See your comment
[here](https://mail-archives.apache.org/mod_mbox/jena-dev/201510.mbox/%3C5610F36D.8090602%40apache.org%3E)
about "other clearing up of DatasetFactory ...", although I'm not sure why Git
created the diff in this confusing way.
> Develop a new
rely on adjacency (and we can't) then I _think_ this is the best we
can do. But I would be very happy to be wrong.
Another alternative would be to require a special kind of returned order in
`QuadTable::find`, but th
methods. I am confused that HexTable and
QuadTableForm both provide QuadTabl. Good that the real code path exploits the
efficiency. `GRAPH ?g {}` which even has a special operator in SPARQL algebra,
is something that users want to be efficient.
> Develop a new in-memory
ds
up all those forms into a structure that acts as _one_ `QuadTable` by selecting
the most efficient form(s) for any given operation. I'll add some comments to
explain that relationship more fully and clearly.
> Dev
?) where it can be done efficiently.
Maybe, an operation like: `QuadTable.findUnique()`. (Adding a flag to
`find()` feels yukky to me - a bias against powerful methods with different
characteristics based on additional arguments).
> Develop a new in-memory RDF Dataset imple
rently handling `listGraphNodes`, as we discuss elsewhere in this PR. I
entirely agree about the preferrable signature. I'll get another commit in on
this point.
> Develop a new in-memory RDF Dataset implementation
> --
uest:
https://github.com/apache/jena/pull/94#issuecomment-155535885
@afs , I've factored a `findInUnionGraph` through the code to provide
access to implementation efficiencies. Let me know what you think!
> Develop a new in-memory RDF Dataset im
public static DatasetGraph createTxMem() { return new
DatasetGraphInMemory(); }
+
--- End diff --
createTxMem => createTxnMem
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-62
public static DatasetGraph createTxMem() { return new
DatasetGraphInMemory(); }
+
--- End diff --
Changed.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
>
uest:
https://github.com/apache/jena/pull/94#issuecomment-155580382
Looks good. Time to think about merging. This is a significant contribution
so I'll send a message to dev@ and formally let people know it is happening
with lazy consensus.
> Develop a new in-memory
uest:
https://github.com/apache/jena/pull/94#issuecomment-155581142
Ah, that is exciting! I will begin learning the documentation CMS so as to
offer a good set of pointers and explanations to help people try this out.
> Develop a new in-memory RDF Dataset impleme
uest:
https://github.com/apache/jena/pull/94#issuecomment-155581224
@afs Shall I squash again in preparation?
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
>
uest:
https://github.com/apache/jena/pull/94#issuecomment-155582207
That would be nice - the merged commits become the "public record" so to
speak so the audience is changing. The journalling separate for the mem
dataset for example.
> Develop a new in-memory RDF Datas
ll add more useful and full commit comments for each.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Pro
ARQ test framework in `/testing`. I think I'm going to have to
come to the list on that, because while I think I can correctly read much of
the RDF that is setting up tests, I can't figure out for the life of me how it
gets executed or how to hook in a section so that my new designs are
after this is merged so we have a stable base to get the
merge done.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
>
cific to these impls, so I
think we're doing pretty good there.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
uest:
https://github.com/apache/jena/pull/94#issuecomment-156135092
and `AbstractTestTransaction`. Think that's it.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
>
uest:
https://github.com/apache/jena/pull/94#issuecomment-156135758
Yep, got that one via
`TestDatasetGraphInMemory.TestDatasetGraphInMemoryTransactions`.
> Develop a new in-memory RDF Dataset implementation
> --
>
>
over order (building
blocks before combinations helps in navigating failures. Putting each nested
class in `TestDatasetGraphInMemory` in a separate files and having TS_ makes
navigation a bit easier in an IDE. [All "IMO".]
> Develop
nd I needed to use the test behavior from many
abstract dataset test classes.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/j
er way.
Shall I make another commit renaming `TestInMemory` to `TS_InMemory` and
breaking apart `TestDatasetGraphInMemory` to a `TS_DatasetGraphInMemory` and
multiple classes like `TestDatasetGraphInMemoryThreading`,
`TestDatasetGraphInMemoryLock`, etc.?
> Develop a new in-m
put a break
point on and it got hit three times.
(Also - running the same test more than on confuses Eclipse in minor ways -
some don't get marked as "run".)
No need to do anything now - lets get the code in.
> Dev
now and stay out of the way. {grin}
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apac
mmit db7104ea845a2486156895e9f691996efad41817 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=db7104e ]
JENA-624: NOTICE, LICENCE, DEPENDENCIES for module inc Dexx Collections
> Develop a new in-memory RDF Dataset im
mmit 5b6a5fe8280b4e97c14bb40258df7256bb2c56c1 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=5b6a5fe ]
JENA-624 : Clean warnings
> Develop a new in-memory RDF Dataset im
mmit 519a8df987dfbee4c347fb50898db939ea0f3ed5 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=519a8df ]
Merge JENA-624 - in-memory transactional dataset contribution.
This closes #94.
> Develop a new in-memory RDF Dataset im
mmit a4b9aa0e96777c1d1456900fd8e23b35725d6a98 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=a4b9aa0 ]
JENA-624: L&N for Dexx collections
> Develop a new in-memory RDF Datase
t at:
https://github.com/apache/jena/pull/94
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
>
[
https://issues.apache.org/jira/browse/JENA-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-624:
---
Labels: java linked_data rdf (was: gsoc gsoc2015 java linked_data rdf)
> Develop a new in-memory
e/g1 http://example/s1 http://example/o1]
{noformat}
Order is PGSO- should be GSPO
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/j
y be useful.
Storing triples in indexes if there have been a reordering is confusing. It
may be better to store a {{Tuple}}. This makes it clear when data is in
"triple space" and when it's in "indexed space" where it may be reordered.
> Develop a new in-m
the commit message:
This closes #98
commit e94c2bfada08b66375e811d899fb2d041520dff7
Author: ajs6f
Date: 2015-11-15T15:12:40Z
Fix for ordering problem in JENA-624
> Develop a new in-memory RDF Dataset impleme
tests for all table orderings.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
&g
n, I will work on using
something like {{ColumnMap}} to clean up this workings and maybe make more
clear how the ordering and "de-ordering" works.
> Develop a new in-memory RDF Dataset implementation
> --
>
>
mmit e94c2bfada08b66375e811d899fb2d041520dff7 in jena's branch
refs/heads/master from [~ajs6f]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=e94c2bf ]
Fix for ordering problem in JENA-624
> Develop a new in-memory RDF Dataset im
t at:
https://github.com/apache/jena/pull/98
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
>
send another PR just to extend
and clarify that new test, so that all of the various triple- and quad-table
orders are being checked and so that it is quite clear what is being checked.
> Develop a new in-memory RDF Dataset impleme
Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
> Issue Type: Improvement
&
mmit f00e659c52d3b9daac4a0ffacf19be1b90c03d60 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=f00e659 ]
JENA-624, JENA-1064: Union graph quads to be Quad.unionGraph.
> Develop a new in-memory RDF Dataset im
mmit f00e659c52d3b9daac4a0ffacf19be1b90c03d60
include the new tests in connection with JENA-1064 to which you refer above?
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apa
ough preparing them was how I found
the issue.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
>
JENA-624
AbstractTest* for the abstract test classes.
TS_ for the test suites.
Collect each TS_* into test suite collection TC_General
> Develop a new in-memory RDF Dataset implementation
> --
>
>
st suites.
Collect each TS_* into test suite collection TC_General
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
>
st suites.
Collect each TS_* into test suite collection TC_General
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
>
st suites.
Collect each TS_* into test suite collection TC_General
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
>
t at:
https://github.com/apache/jena/pull/100
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
>
mmit fb653e3e5e3ad6e4229d728e55c60b08ca5b59c2 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=fb653e3 ]
JENA-624: Fix reordering error on rebuilding quads for OSGP.
> Develop a new in-memory RDF Dataset im
mmit 6dbdc0c8eaf30d74dc11860e9e62d1496184a082 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=6dbdc0c ]
JENA-624: Clean examples and use the transactional in-memory dataset.
> Develop a new in-memory RDF Dataset im
mmit b2089224c07d50b0b85d9c915cecff73bb809a4b in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=b208922 ]
JENA-624: Implement DatasetGraph.size().
> Develop a new in-memory RDF Dataset im
mmit b65974f7cff91712def03bfc3ea253b6ec20ff68 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=b65974f ]
JENA-624: Parameterize and run on both "general" and "txn mem" datasets.
> Develop a new in-m
mmit 27f732c5cf1995d70eba81b52c204cb42779f181 in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=27f732c ]
JENA-624: Use Dataset.createGeneral() as general filler/default.
> Develop a new in-memory RDF Dataset im
let {{TupleTable}} offer a
{{size}} method. Using {{Stream::count}} like you did will incur some amount of
cost that is unnecessary in many cases (like the current impl). What do you
think?
> Develop a new in-memory RDF Dataset impleme
mmit 1fa20a279f5251854bc9b3f70c5325b9100acb7b in jena's branch
refs/heads/master from [~andy.seaborne]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=1fa20a2 ]
JENA-624: Specific to general Dataset
> Develop a new in-memory RDF Dataset im
ize()}}
but changing it is disruptive.
Best I can think of is to have two operations {{numGraphs}} and {{numQuads}}.
The quads count would include the default graph.
> Develop a new in-memory RDF Dataset implementation
> --
>
they each represent. Or maybe that can happen at
{{TupleTable}}. It might clarify some of the other code there, and help
generify the places (like here and {{listgraphNodes}} where we penetrate
abstractions for the sake of performance.
> Develop a new in-m
an RC for this work into 3.0.1 is
important IMO. Some codebase stability would be good and what there is
currently works. The current critical path item is documentation.
> Develop a new in-memory RDF Dataset implementation
> --
>
>
n in favor of docs?
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
>
7;t think {{listGraphNodes}}
optimization should go in until after the release.
If you want to sketch out your ideas for the documentation, then I can help
complete it.
> Develop a new in-memory RDF Dataset implementation
> --
>
>
the docs.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
>
the commit message:
This closes #103
commit c9b292293d307de305700981adb3d2d6d424d732
Author: ajs6f
Date: 2015-11-30T18:23:34Z
Correction to transaction begin for DatasetGraphInMemory to include default
graph as well as quad table.
> Develop a new in-memory RDF
adoc).
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
> Issue Type: Improvement
&g
{{end}} also to possess the semantic of "clean up and release any
state associated to the transaction". Is that not so? That's why I reused
{{end}} to do the same work as part of {{abort}}. See
{{DatasetGraphWithLock::_abort}} for what I think is the same pattern.
> Develop
now.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
> Issue Type: Improvem
aultGraph().end();
isInTransaction(false);
transactionType(null);
getLock().leaveCriticalSection();
}
{noformat}
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
>
ontrol to external code.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
>
a little confused about your remark "The lock may (dubiously)
be protecting other code but is not MRSW safe." The lock in question is
{{LockMRPlusSW}}, which is very much designed to be MRSW safe, although of
course there are always bugs!
> Develop a new
proposed fix is the {{if (!isInTransaction()) return;}} to make {{end()}}
idempotent at the end of a transaction until the thread starts a new one.
Aside: there only needs to be {{isInTransaction}} in {{DatasetGraphInMemory}}
because it wraps {{Hextable}}/{{TriTable}}.
> Develop a new i
make that easier: e.g. [mantis
TransactionCoordinator|https://github.com/afs/mantis/blob/master/dboe-transaction/src/main/java/org/seaborne/dboe/transaction/txn/TransactionCoordinator.java]
but I'm not sure its all the way there yet.
> Develop a new in-memory RDF Datas
right that it could create a problem. I'll take in
your fix and add it to PR #103 with the test for which you asked above.
Can you expand your remark about {{isInTransaction}} in
{{DatasetGraphInMemory}}? It's a bit too gnomic for me. :)
> Develop a new in-memory
etty helpless in the fact of
multi-thread transactions. That's a whole new frontier! :)
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.
} in {{DatasetGraphInMemory}}. The others
don't seem to add anything. All calls go via {{DatasetGraphInMemory}}.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issue
e is supposed to be MRSW itself (e.g. the
rules system) and MR+SW lets in situations that conflict with MRSW.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apa
} in {{DatasetGraphInMemory}}. The others
don't seem to add anything. All calls go via {{DatasetGraphInMemory}}.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issue
ends {{Transactional}} to
provide for coupling tables together in the manner of {{HexTable}} or
{{TriTable}}. So that's why {{isInTransaction}} is in the mix there.
> Develop a new in-memory RDF Dataset implementation
> --
>
>
eird to me, but I clearly
don't understand the use of {{getLock}} yet. I'll take a look at how it used in
the rules system to try and understand better.
> Develop a new in-memory RDF Dataset implementation
> --
>
>
#103, so please don't merge it
until I have a chance to squash them.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
t at:
https://github.com/apache/jena/pull/103
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
>
uest:
https://github.com/apache/jena/pull/103#issuecomment-161800617
This is important to get in and i don't want it to miss the release so
applied as-is. Also applied a test in `end()` for being called multiple times.
> Develop a new in-memory RDF Dataset im
via {{DatasetGraphInMemory}} which has it's
own {{isInTransaction}}. {{TupleTable}} can inherit {{Transactional}} for the
interface operations and does not imply that the internal units of {{HexTable}}
or {{TriTable}} have to check again.
> Develop a new in-memory RDF Dataset im
are_ implementations of
{{TupleTable}}.
> Develop a new in-memory RDF Dataset implementation
> --
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache
601 - 700 of 1081 matches
Mail list logo
