Hi,
first of all, thank you for your patch.
I had a quick look, but I did not try to apply it (yet).
May I ask how you created your patch?
We added a section on the Getting Involved page on the Jena website:
"Patches should be attached to issues in Jira (click on
More Actions > Attach Files). To create a patch you can simply
use the command:
svn diff > JENA-XYZ.patch
Please, inspect your patch and make sure it includes all (and only)
the relevant changes for a single issue. Don't forget tests! If you
want to test if a patch applies cleanly you can use:
patch -p0 < JENA-XYZ.patch
If you use Eclipse: right click on the project name in Package Explorer,
select Team > Create Patch or Team > Apply Patch."
- http://jena.staging.apache.org/jena/getting_involved/#submit_your_patches
It really helps if a patch contains only the lines you added|removed
and it applies cleanly. It saves a lot of time and speed-up reviewing
it.
Your patch may be perfectly fine, but I wanted to take the opportunity
to send the message across.
I am really curious to run a few benchmarks when it's done to compare
MonetDB with a more traditional SQL system.
By the way, about benchmarks Andy is (secretely) working on this:
https://svn.apache.org/repos/asf/incubator/jena/Experimental/JenaPerf/trunk/
I have not time to try it yet, but it seems very interesting. :-)
Thank you again for the new interesting feature.
Paolo
nat lu wrote:
> Added, with patch file, at
>
> https://issues.apache.org/jira/browse/JENA-134
>
>
> I have made no more progress on testing it out other than sdbconfig so
> far, hope too soon.
>
>
> On 09/09/11 16:43, Paolo Castagna wrote:
>> Hi,
>> why don't you open a new JIRA issue (as a New Feature) for this?
>> https://issues.apache.org/jira/browse/JENA
>>
>> You can then attach a patch to it. This way others can look at what
>> you have done so far (and maybe help you out).
>>
>> Thanks for your help,
>> Paolo
>>
>> nat lu wrote:
>>> I made a start, and tried to use one of the existing flavours, but ended
>>> up creating one for MonetDB - combination of derby and DB2. It doesnt
>>> like longs or unbounded varchars.
>>>
>>> So, I got as far as getting SDBConfig to complete, but havent done an
>>> sdbload yet
>>>
>>>
>>> On 09/09/11 10:37, Andy Seaborne wrote:
>>>>
>>>> On 04/09/11 13:03, nat lu wrote:
>>>>> I'm going to give it a go sometime soon and report back on my
>>>>> non-scientific findings. Your point about the small number of
>>>>> columns is
>>>>> well made, but the research paper cited earlier also mentions this and
>>>>> reports that because of column store optimisations even when they
>>>>> vertically partitioned their data rather than using a property-table
>>>>> approach they still saw good improvement. However, again, I'm no
>>>>> column
>>>>> store expert so perhaps I'm missing some point here :-). Anyway,
>>>>> time to
>>>>> "suck it and see@, all in the name of progress of course.
>>>>>
>>>>> On 03/09/11 16:29, David Jordan wrote:
>>>>>> I have not used a column-oriented database, but I am somewhat
>>>>>> familiar
>>>>>> with them. My understanding of them is that the storage is
>>>>>> partitioned
>>>>>> on a column basis, such that there is no physical clustering together
>>>>>> of all the columns for a given row. An advantage of this would be in
>>>>>> the case where you have tables with many columns, but the particular
>>>>>> application only needs a small subset of columns.
>>>>>>
>>>>>> With the SDB representation of triples (3 columns) and quads (4
>>>>>> columns), and access typically based on having a specific value for
>>>>>> one or two of the columns, I am not so sure that a column-based
>>>>>> approach would offer any advantage.
>>>>>>
>>>>>> But again, I am no expert on these types of databases.
>>>>>>
>>>>>> These discussions about alternative datastore representations RDF/OWL
>>>>>> data are very useful, to gain better understanding of which data
>>>>>> architectures yield the best implementation approach for
>>>>>> high-performance.
>>>>>>
>>>>>> p.s. I Monet provides support for JDBC, I would not think much effort
>>>>>> is needed to support in with SDB.
>>>> Shouldn't be too hard :-) SDB targets SQL-92 and there are a few
>>>> extension points to cope with the vagaries of different SQL engines.
>>>> It's one of the reasons there are ~10 small files to write, to capture
>>>> the uniqueness of each SQL syntax.
>>>>
>>>> Andy
>
