Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
One question with passing in a builder is the extent to which clients will
be reusable. Perhaps that's where setting a default client or using the
custom-client-per-service feature (available now) would
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@afs Said "(It seems odd that the can't get the setting out of an
HttpClient to feed into a builder.)"
YES. It is _intensely_ annoying. It seems like a massive oversight to me,
but a
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@afs Yes, the addition of `HttpOp` methods as you describe is what I was
thinking of. Not too much there, but enough to let people move their own
`HttpContext`s around, which would be pretty darn handy
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/154#discussion_r70663415
--- Diff:
jena-tdb/src/main/java/org/apache/jena/tdb/transaction/TransactionManager.java
---
@@ -436,8 +469,96 @@ public void notifyAbort(Transaction
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@paulhoule One difficulty with `HttpRequestInterceptor` is a good thing to
bring up-- in the newer HTTP Commons client APIs, clients are immutable and if
you want to add, e.g., interceptors, you need
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@paulhoule There is `org.apache.http.HttpRequestInterceptor`, which I think
is what HTTP Commons itself supplies for that kind of purpose. But there are
also a host of parts built into the rest
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
@rvesse : Basically, I think we share the same picture of the situation. I
wouldn't claim that this new API presents quite the same "ergonomics" as what
we now have. I think the heart of
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/151#discussion_r70630354
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/engine/http/HttpQuery.java ---
@@ -298,6 +292,19 @@ public InputStream exec() throws QueryExceptionHTTP
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Right, I think we're fine as long as Jena itself is actually the client
(e.g. as part of `SERVICE` action in a query). It was the situation in which
some app is using HTTP via `HttpOp` in which an input
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/133
Would that (new API) look like a set of wrappers? Or perhaps a method on
`Model` that reflects the instance into an `AutoCloseable` subtype of `Model`?
---
If your project is set up for it, you can
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
Reading through the current HTTP Commons docs leaves me with the impression
that we do not need to close clients after use in `HttpOp`, but that we do need
to see to it that _responses_ are closed
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
[A useful description of
`HttpContext`.](https://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html#d5e223)
---
If your project is set up for it, you can reply to this email
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/153
Okay, so the appropriateness of `finally` depends on where you are (app vs.
system code). Makes sense.
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/95
So the caching in this scenario, @afs, would be handled by
`QueryEngineHTTP`/`QueryExecutionBase`?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/153
We usually use `try-finally` for the transaction cycle, i.e.
```
try {
transactionalThing.begin(readWrite);
//do some stuff
transactionalThing.commit(); // if a write
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/153#discussion_r70181662
--- Diff: jena-arq/src/main/java/org/apache/jena/system/ThreadTxn.java ---
@@ -0,0 +1,148 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
I'm imagining a bag of new methods in `HttpOp` similar to what's there now,
with the additional `HttpContext` param, and the methods that are now there
would call through those new methods with `null
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
As I understand it (for what that's worth) `HttpContext` is mostly about
the idea of a "conversation", so if you've got some kind of session going on,
or a series of request-response cycles th
Github user ajs6f commented on the issue:
https://github.com/apache/jena/pull/151
I'm not totally clear about the style for `CloseableHttpClient`, either.
I'll poke around and see if I can get a better reading on that. And I'll start
jotting up some docs.
---
If your project is set
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/152#discussion_r70116076
--- Diff: jena-arq/src/main/java/org/apache/jena/sparql/graph/GraphOps.java
---
@@ -29,60 +29,49 @@
import org.apache.jena.sparql.core.Quad
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/151
FCREPO-576: Moving away from deprecated HttpCommons Client API
This is a bit of a shake-up in the HTTP machinery, but as per discussion
with @afs , a "big bang" discarding the use of mu
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/142
Version bumps
There are two commits in this PR. The first, I think, should be entirely
straightforward. The second contains a minor version bump for `mrunit`. In
order to do this, I updated
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/139#discussion_r62355638
--- Diff:
jena-arq/src/test/java/org/apache/jena/riot/writer/TestJsonLDWriter.java ---
@@ -0,0 +1,457 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/139#discussion_r62354809
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/out/JsonLDWriter.java
---
@@ -79,26 +130,85 @@ public void write(OutputStream out, DatasetGraph
dataset
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-213500724
On the question of conditional-GET, there has been some
[discussion](https://pony-poc.apache.org/thread.html/Zdrf49p8jphmwje) about
ETags in this connection that might
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-213468612
:+1: @osma++
Part of the takeaway here for me is that when it comes to caching bits,
we're unlikely ever to do as well as specialist tools that have been carefully
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-212574529
@samaitra
`ResultSetMem` speaks to your problem of exhaustion. It caches the results
in the heap and can be "rewound" and even O(1) copied.
---
If yo
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-212502652
Ooh, sorry-- didn't catch that about SELECT-only.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/95#issuecomment-212405267
Another +1 to @osma's comments. In re: serialization: it seems to me that
the need here is for "replay-ability". Certainly serialization will do that,
but at a
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/136#discussion_r60235133
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/system/RiotLib.java
---
@@ -73,12 +78,37 @@ public static Node createIRIorBNode(String iri
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/136#discussion_r60233218
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/system/RiotLib.java
---
@@ -73,12 +78,37 @@ public static Node createIRIorBNode(String iri
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/136#discussion_r60230353
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/system/RiotLib.java
---
@@ -73,12 +78,37 @@ public static Node createIRIorBNode(String iri
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/136#discussion_r60229859
--- Diff: jena-arq/src/main/java/org/apache/jena/riot/system/RiotLib.java
---
@@ -73,12 +78,37 @@ public static Node createIRIorBNode(String iri
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/134#discussion_r59385695
--- Diff:
apache-jena-osgi/jena-osgi/src/main/java/org/apache/jena/osgi/Activator.java ---
@@ -0,0 +1,47 @@
+package org.apache.jena.osgi;
+
+import
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-207436679
Dexx Collections has released a `0.6` with OSGi metadata, and I've updated
https://github.com/apache/jena/pull/135 to refer to it, so if we order that PR
before this one
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/134#discussion_r58941531
--- Diff:
apache-jena-osgi/jena-osgi/src/main/java/org/apache/jena/osgi/Activator.java ---
@@ -0,0 +1,47 @@
+package org.apache.jena.osgi;
+
+import
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-206902158
Marvelous! I'll circle back with them and with any luck, we'll get a
release eftsoons with the new metadata.
---
If your project is set up for it, you can reply
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-206524142
Dexx Collections has
[merged](https://github.com/andrewoma/dexx/commit/7d0f242e64679b4f3fd4a5ee0598d29852df49ce)
my PR to give OSGi metadata to their Java artifact
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-206462555
I've sent an [issue](https://github.com/andrewoma/dexx/issues/6) and
[PR](https://github.com/andrewoma/dexx/pull/7) to Dexx Collections to get the
OSGi metadata
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/135#issuecomment-206452035
Oops, disregard previous comment: I misunderstood some advice from the Dexx
Collection maintainers and upgraded somehow to a Kotlin version of the library
instead
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/135#issuecomment-206447863
This PR would pull in Kotlin's runtime to the dependencies, because Dexx
Collections has moved to Kotlin for current versions. Obviously, that warrants
discussion
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-206433254
No, it's not the _presence_ of MAINFEST.MF (which I think tends to appear
in pretty much any JAR or WAR). It's what's in it. There are specific headers
in an OSGi version
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/135
JENA-1160: Upgrade Dexx Collections version
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/jena JENA-1160
Alternatively you can review
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-206409700
OSGi requires some [metadata](https://en.wikipedia.org/wiki/OSGi#Bundles)
to work, found in the `MANIFEST.MF` in `META-INF`. Most projects have that
auto-created
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-205975853
To create the OSGi bundle for Dexx, did you use any tooling, or just insert
a manifest manually? I'd like to send them a PR (or of course, you can :) ).
---
If your
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/134#issuecomment-205400464
I will try and contact the maintainers of Dexx Collections to see if we can
get a properly OSGI-ified release there. Also, they appear to have released a
new version 0.5
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/131#discussion_r57891292
--- Diff:
jena-text/src/test/java/org/apache/jena/query/text/TestDatasetWithAnalyzingQueryParser.java
---
@@ -0,0 +1,64 @@
+/**
+ * Licensed
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/131#discussion_r57889145
--- Diff:
jena-text/src/test/java/org/apache/jena/query/text/TestDatasetWithAnalyzingQueryParser.java
---
@@ -0,0 +1,64 @@
+/**
+ * Licensed
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/128#discussion_r55195827
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/system/FactoryRDFCaching.java ---
@@ -0,0 +1,110 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/128#discussion_r55195636
--- Diff:
jena-arq/src/main/java/org/apache/jena/riot/system/FactoryRDF.java ---
@@ -0,0 +1,56 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r52173358
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/build/RefCountingMap.java
---
@@ -0,0 +1,187 @@
+/**
+ * Licensed
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r52172791
--- Diff:
jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/build/DescriptionToDatasetMap.java
---
@@ -0,0 +1,48 @@
+/**
+ * Licensed
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/120#issuecomment-177313470
Sorry on both counts. `SimpleMap*` is leakage from JENA-1084. My Git-fu
failed. I thought I had kept that work separate.
---
If your project is set up for it, you can
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/124
Add Javadoc for Assembler indicating that Model values are advisory
Attempting to capture @afs's comment
[here](https://github.com/apache/jena/pull/123#issuecomment-174306928) as
advice
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/123#issuecomment-174658906
Is there any understanding about the sharing of components between the
results of calls to the various forms of `Assembler::open`?
---
If your project is set up
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/123#issuecomment-174299109
Just as a sidenote, isn't `org.apache.jena.assembler.Mode` intended to
control whether new things are created or old things are reused during the
assembly?
---
If your
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/123#issuecomment-174311642
Thanks for the clarification re: `Mode`. Should the Javadocs for `Mode` say
that something like that it "advises implementations of user intention, but
does not cons
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/123#issuecomment-174311885
There has been some
[discussion](http://markmail.org/message/6uab6glusw7lqpmz) about the
commonalities between `jena-text` and `jena-spatial`. Is the same problem
likely
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50548291
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/TextDatasetFactory.java ---
@@ -191,5 +213,50 @@ public static DatasetGraph
createSolrIndex
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50538146
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/assembler/TextIndexLuceneAssembler.java
---
@@ -47,8 +59,9 @@
text:entityMap <#end
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50540841
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/assembler/TextIndexLuceneAssembler.java
---
@@ -123,10 +141,35 @@ public TextIndex open(Assembler
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50541229
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/assembler/TextIndexLuceneAssembler.java
---
@@ -61,7 +74,12 @@ public TextIndex open(Assembler
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50542029
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/TextDatasetFactory.java ---
@@ -191,5 +213,50 @@ public static DatasetGraph
createSolrIndex
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50537882
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/TextIndexLucene.java ---
@@ -399,4 +404,24 @@ private Node entryToNode(String v
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/123#discussion_r50546226
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/assembler/TextIndexLuceneAssembler.java
---
@@ -61,7 +74,12 @@ public TextIndex open(Assembler
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/120#issuecomment-172877393
I'm happy to do whatever will get this merged and move on. I chose the
prefix names and not the numerical suffix names because that is what Java does
in (e.g
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/119#issuecomment-170342439
It reads more clearly to me, but I'm just one data point. {grin}
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/120#discussion_r49275522
--- Diff:
jena-base/src/main/java/org/apache/jena/atlas/lib/tuple/QuadConsumer.java ---
@@ -0,0 +1,47 @@
+/*
+ * Licensed to the Apache Software
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/119#issuecomment-170371507
But `getOrFill` is not new with Java 8, is it?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/120#issuecomment-170022965
I've changed `TupleMap` back to `final`, with concomitant changes to the
subclasses of `PMapTupleTable`.
---
If your project is set up for it, you can reply to this email
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/120#discussion_r49192464
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/PMapQuadTable.java ---
@@ -37,13 +39,29 @@
* use.
*
*/
-public abstract
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/120#issuecomment-170033484
Reformatted license headers.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/120#issuecomment-169384106
Third time is the charm!
I think this time I have a good factoring that begins to separate the
notion of ordering from the kind of data structure which stores
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/120#issuecomment-169393952
Oops! Adding a last commit to keep all the ordering machinery more
centralized.
---
If your project is set up for it, you can reply to this email and have your
reply
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/120
JENA-1083: Factoring tuple ordering into TupleMap
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/jena JENA-1083
Alternatively you can
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/119#issuecomment-169147952
I wonder if it is better to rely directly on the Guava classes here or to
try to use a `org.apache.jena.atlas.lib.Cache<>`?
---
If your project is set up for it, y
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/119#discussion_r48902208
--- Diff:
jena-text/src/main/java/org/apache/jena/query/text/TextQueryPF.java ---
@@ -268,7 +276,25 @@ private QueryIterator concreteSubject(Binding binding
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/118#issuecomment-168695738
+1 to the general plan here, definitely. Is the future plan to migrate the
namespaces as well?
---
If your project is set up for it, you can reply to this email and have
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/118#issuecomment-168724113
Right, that's why I said "re-appear". They appear in the original modules,
and now in the new one. As I wrote, it's not anything to worry about and mostly
jus
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/118#issuecomment-168719708
Okay. I found it odd that so many package names re-appear in the new
artifact. I'm used to OSGi habits, but this is nothing to cavil at, just my
predilections
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/117#issuecomment-168308691
This PR builds with `mvn clean install` or, to be extra-sure:
```
mvn clean dependency:purge-local-repository -DreResolve=false
mvn install
```
---
If your
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/117#issuecomment-168305858
Having the [optional
tag](https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html)
doesn't prevent Jena from using
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/117
JENA-583: Using Maven optional tag for log4j dependencies
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/jena JENA-583
Alternatively you
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/110#issuecomment-168017857
Closing in favor of finding a different approach.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/110#issuecomment-168017775
Well, this branch is clearly not worth rebasing post #115, and I haven't
run a profiler on it anyway. I'll take a look at `TripleOps` and think a little
more about
Github user ajs6f closed the pull request at:
https://github.com/apache/jena/pull/110
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/110#issuecomment-167593138
1. I totally understand that changing `Triple` and `Quad` is significant,
so that caution is the order of the day.
2. I'm not sure of what you mean by the "com
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/115#discussion_r48498599
--- Diff:
jena-base/src/main/java/org/apache/jena/atlas/lib/tuple/Tuple.java ---
@@ -0,0 +1,73 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/115#discussion_r48498210
--- Diff:
jena-base/src/main/java/org/apache/jena/atlas/lib/tuple/Tuple.java ---
@@ -0,0 +1,73 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/115#discussion_r48498336
--- Diff:
jena-base/src/main/java/org/apache/jena/atlas/lib/tuple/Tuple.java ---
@@ -0,0 +1,73 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/110#issuecomment-167630549
Do you want me to close this in light of #115 ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/113
JENA-1103: Skip editor backup files in configuration directory
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ajs6f/jena JENA-1103
Alternatively
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/109#issuecomment-164756367
I suppose it's early days in that sense. But if (as seems at least
possible) Jena acquires more and more kinds of indexes (text, geospatial, etc.)
and more and more
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/108#issuecomment-164423186
I guess I thought of this "lock" as a semaphore. I've not heard the term
"latch" used in this context. In any event, it is a `private` variable, as yo
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/108#issuecomment-164426433
That might be a good idea. If I understand correctly where you're taking
this, we have a lock that must be acquired to change transactional state (for
example, to commit
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/108#issuecomment-164419995
If it's a problem with the fact that the former `commitLock` is now being
used for other transaction moments as well, I get that. But `systemLock` is
pretty generic and I
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/108#issuecomment-164418205
But the `writeLock` isn't used directly by applications either. Why aren't
they both "system locks"?
---
If your project is set up for it, you can reply to
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/109#issuecomment-164436772
I think this is basically awesome. Separating different views of the
things-that-are-transacting is good, and it gets us a little further down the
road to having a proper
GitHub user ajs6f opened a pull request:
https://github.com/apache/jena/pull/110
JENA-1083: Using ColumnMap in transaction in-memory dataset implementation
Okay, @afs : Second try. This time I avoid unneeded object creation or
packing and unpacking, and I don't do weird things
Github user ajs6f commented on a diff in the pull request:
https://github.com/apache/jena/pull/108#discussion_r47445019
--- Diff:
jena-arq/src/main/java/org/apache/jena/sparql/core/mem/DatasetGraphInMemory.java
---
@@ -125,57 +115,104 @@ public DatasetGraphInMemory(final
701 - 800 of 1019 matches
Mail list logo
