[GitHub] jena issue #204: One writable graph per thread/transaction dataset

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/204
  
Closing in favor of further more general discussion about points raised on 
this PR.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #204: One writable graph per thread/transaction dataset

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/204
  
I'm starting to wonder whether I should back up here and just go for the 
more general 2-phase-locking design as [@afs discusses in the Jira 
ticket](https://issues.apache.org/jira/browse/JENA-1274?focusedCommentId=15809288=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15809288),
 or even to try to generalize to more amorphous locking regions. Doing those 
things would open up more use cases which might make this stuff viable for 
`jena-arq` itself.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #204: One writable graph per thread/transaction dataset

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/204
  
Yeah, judging by the general silence in response to my question about "Does 
anyone have other use cases for this kind of thing?" I'm not going to push on 
that I'm happy for it to be helpful to the LDP use case. But I don't want to 
oversell that either. I don't know that Jena would want to house an LDP impl or 
that I would want to do that here. Hm. Well, one question is whether we think 
that there ever would be a full-on `jena-ldp`?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #204: One writable graph per thread/transaction dataset

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/204
  
Possible naming approaches:

1. "Small things" being curated go into a general 
`jena-extras`/`jena-wip`/`jena-labs`/`jena-optional` module with the idea that 
that is just while they mature,  Downside: things go into that module and  
don't progress.
2. At the other end of the spectrum, this is a step for `jena-ldp` so to 
get attention on that, use that name. Downside: over selling.
3. Specific for this one thing: `jena-writer-dsg`, a name for the 
write-centric dataset. Downside: does not connect to LDP usage.







---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #204: One writable graph per thread/transaction dataset

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/204
  
It looks like in order to put this in `jena-extras`, I will need to create 
a new modules there. Any opinions about the name? Maybe 
`jena-optional-datasets` or something like that?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #204: One writable graph per thread/transaction dataset

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/204
  
I will retarget this at jena-extras. It does make more sense.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #204: One writable graph per thread/transaction dataset

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/204
  
That's a really fair point about providing some use cases. An example that 
occurs to me is RDF-based persistence where Java entities are being saved into 
a dataset. I think @claudenw has something like that going on in PA4RDF. This 
kind of dataset could act as a simple but powerful cache for that kind of 
system.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [GitHub] jena issue #204: One writable graph per thread/transaction dataset

[Andy Seaborne]

+1 to extras.

I think that has a lot of merit for small things to be in extras.  It is 
easier to point at and say "new - subject to change".


As does separate github repos - especiallty where the early status is 
unstable, where access while being developed for a the most intersted 
people is not affected by Jena release cycles.



One of the questions I'm trying to raise with this PR is exactly

> that-- is this useful only for LDP-type workloads (in which case maybe
> it belongs outside ARQ entirely) or not (in which case it has more
> claim to be in ARQ)?

How about describing some use case where you think it might be helpful?

Just having something in the codebase does not really ask the question 
you have about what might be - code tends to ask "does this exact thing 
do ..."


Andy

On 11/01/17 20:08, A. Soroka wrote:

Sure, that would be natural. Let me put the question this way: is a per-graph 
arrangement of this kind interesting to anyone who isn't interested in LDP?

The other direction here is forward with respect to locking. Claude and others 
(including me) have thrown around ideas on the list about how we could 
introduce more finely-grained locking for datasets, and I definitely think of 
this as a first tiny baby step in that direction.

---
A. Soroka
The University of Virginia Library


On Jan 11, 2017, at 2:58 PM, Claude Warren  wrote:

perhaps in extras?

On Wed, Jan 11, 2017 at 7:39 PM, ajs6f  wrote:


Github user ajs6f commented on the issue:

   https://github.com/apache/jena/pull/204

   `pergraph`: Just thought that `core` was getting awfully crowded. I
don't care one way or the other-- happy to put them anywhere.

   `jena-ldp`: One of the questions I'm trying to raise with this PR is
exactly that-- is this useful only for LDP-type workloads (in which case
maybe it belongs outside ARQ entirely) or not (in which case it has more
claim to be in ARQ)?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---





--
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [GitHub] jena issue #204: One writable graph per thread/transaction dataset

[A. Soroka]

Sure, that would be natural. Let me put the question this way: is a per-graph 
arrangement of this kind interesting to anyone who isn't interested in LDP? 

The other direction here is forward with respect to locking. Claude and others 
(including me) have thrown around ideas on the list about how we could 
introduce more finely-grained locking for datasets, and I definitely think of 
this as a first tiny baby step in that direction.

---
A. Soroka
The University of Virginia Library

> On Jan 11, 2017, at 2:58 PM, Claude Warren  wrote:
> 
> perhaps in extras?
> 
> On Wed, Jan 11, 2017 at 7:39 PM, ajs6f  wrote:
> 
>> Github user ajs6f commented on the issue:
>> 
>>https://github.com/apache/jena/pull/204
>> 
>>`pergraph`: Just thought that `core` was getting awfully crowded. I
>> don't care one way or the other-- happy to put them anywhere.
>> 
>>`jena-ldp`: One of the questions I'm trying to raise with this PR is
>> exactly that-- is this useful only for LDP-type workloads (in which case
>> maybe it belongs outside ARQ entirely) or not (in which case it has more
>> claim to be in ARQ)?
>> 
>> 
>> ---
>> 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 is enabled but not working, please
>> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
>> with INFRA.
>> ---
>> 
> 
> 
> 
> -- 
> I like: Like Like - The likeliest place on the web
> 
> LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [GitHub] jena issue #204: One writable graph per thread/transaction dataset

[Claude Warren]

perhaps in extras?

On Wed, Jan 11, 2017 at 7:39 PM, ajs6f  wrote:

> Github user ajs6f commented on the issue:
>
> https://github.com/apache/jena/pull/204
>
> `pergraph`: Just thought that `core` was getting awfully crowded. I
> don't care one way or the other-- happy to put them anywhere.
>
> `jena-ldp`: One of the questions I'm trying to raise with this PR is
> exactly that-- is this useful only for LDP-type workloads (in which case
> maybe it belongs outside ARQ entirely) or not (in which case it has more
> claim to be in ARQ)?
>
>
> ---
> 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 is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>



-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

[GitHub] jena issue #204: One writable graph per thread/transaction dataset

[ajs6f]

Github user ajs6f commented on the issue:

https://github.com/apache/jena/pull/204
  
`pergraph`: Just thought that `core` was getting awfully crowded. I don't 
care one way or the other-- happy to put them anywhere.

`jena-ldp`: One of the questions I'm trying to raise with this PR is 
exactly that-- is this useful only for LDP-type workloads (in which case maybe 
it belongs outside ARQ entirely) or not (in which case it has more claim to be 
in ARQ)?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jena issue #204: One writable graph per thread/transaction dataset

[afs]

Github user afs commented on the issue:

https://github.com/apache/jena/pull/204
  
Immediate reaction: Why are the tests in "pergraph"?

If this is the beginning of "jena-ldp", do we want a package under src/main?




---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---