[Nepomuk] Re: First problems with query API

[Sebastian Trüg]

On 03/03/2011 10:03 PM, Ignacio Serantes wrote:
> 
> On Thu, Mar 3, 2011 at 8:22 PM, Sebastian Trüg <trueg at kde.org
> <mailto:trueg at kde.org>> wrote:
> 
>     >
>     > When you told me that I must use the API, I did a try and found this
>     > problem. You can't add a class with a constructor that supports 6
>     terms
>     > but if you use it you crash DBMS or, when you use more than 3
>     terms dbms
>     > freezes, at least with my data. I don't need to explain you the
>     reasons
>     > why this kind of stuff must be controlled at API level ;).
> 
>     There is not only LiteralTerm. You can combine all sorts of terms with
>     AndTerm. And only because it is possible to create a crazy query this
>     way does not mean it needs to be removed completely.
> 
> 
> Not removed, but controlled. As I told you there is a constructor with 6
> terms so is easy to guess that you can add 6 terms without problem and
> this is not true.
> 
> A basic control is easy to implement. For example, if you need to
> generate 30 variables to construct the query probably the query
> execution will kill the dbms. It's so simple put this control and, if
> developers whats to use this queries they must add and additional parameter.
> 
> This kind of control is easily override but it's useful to stop bad, not
> tested code and, commonly, developer mistakes. With this additional
> security check bad programs will obtain empty results and an error but,
> the important is that virtuoso is safe.
>  
> 
>     > By the way, as always I need to do more tests, understand how db is
>     > organised and where users need to do a search before I obtain
>     > conclusions that could be useful to you but, sadly, I'm very short in
>     > free time and Ksoprano is useful but annoying. I think I must write my
>     > own tool to work with sparql and be more productive.
> 
>     Give Nepomukshell a try and please, before you write your own tool,
>     consider contributing to that or at least tell us what needs to be
>     improved.
> 
> I did it but is worst to me than ksoprano. These are the requirements
> that Nepomukshell don't cover:
> 1) Error handling. I do a mistake but no error is displayed so is
> difficult to wonder what is happening and this is a big problem if you
> are trying to learn Sparql. This is the main reasons why I choose Ksoprano.

Makes perfect sense. Easy to add.

> 2) Load and save queries.

You mean loading from file?

> 3) Load and save sessions or, at least, last session. I can finish a
> session perfectly with over 20 different queries opened so I need to
> manually save all to next day.

ok.

> 3) Before and after are confusing, and I have many queries opened at
> same time. I'm a tab guy and the other reason I'm using Ksoprano.

tabbed queries should also be easy. Could be copied over from ksoprano.

> 4) Batch testing and test substitution to test the same query with
> different terms. I'm doing this with a text file with all queries I want
> to test and an python script but is far to be comfortably.

Any ideas as to how the gui could look?

> by the way, syntax coloring and auto-completion are really cool :). As
> you can see my requirements are very specific and probably outside the
> scope of the Nepomuk Shell. But I confess you that even for other stuff
> I prefer Ginkgo over Nepomuk Shell. I'm really comfortably with Ginkgo
> interface and remembers my last session.

Ginkgo is intended for the end user. Nepomukshell is intended for the
developer as a testing and debugging shell.

> Of course I would be happy to contribute whatever I can to Nepomuk, I
> like very much some aspects of this project, and I really want that
> works because I'm trying to using it for long time ago, but I'm not
> interested in learn C/C++ and even less in develop in it. I never have
> any pleasure writing C/C++ code and I'm doing this as a hobby in my free
> time. With pleasure I will try to contribute with sparql knowledge, when
> I have knowledge to share, or contributing with Python, Ruby, Lua or any
> high level language you can imagine.
> 
> -- 
> Cheers,
> Ignacio
> 
> 
> 
> 
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk