Re: Class inheritance - unexpected behaviour?
Hi Thorsten, ,-- | (class +a) | (rel a1) | | (class +b +a) | (rel b1) | | (class +C +b) | (rel C1) | | (class +D +a) | (rel D1) `-- now ,--- | (select a1 +C) `--- and ,--- | (select a1 +D) `--- both show me all objects that somehow inherited attribute 'a1', although they only have the same root of the class hierarchy (+a), where the attribute is defined, but do not belong to the same branches of the hierarchy. I do not know what the relations 'rel' are, i.e. which indexes they have and, how these indexes are populated. But in general, note that (select a1 +C) reads SELECT a1 from C. This means, you specified no search criterion at all. 'select' is a bit tricky, it tries to find out what you want to do. If you want SELECT * from C where a1 = xxx you would do (select +C a1 abc) This 'show's all objects completely, not just the 'a1' property. If you don't give a relation (index) to search for, 'select' tries to find a suitable index by itself by doing some heuristic guesses. This is because the PicoLisp database doesn't enforce any attributes or indexes, and it highly depends on the application how to find which data. And you should keep in mind that 'select' is just a help for debugging. It cannot be used in an application. For precise searches, use the 'select' and 'db' Pilog queries, or the 'db' and 'collect' Lisp functions. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Class inheritance - unexpected behaviour?
Alexander Burger a...@software-lab.de writes: Hi Alex, ,-- | (class +a) | (rel a1) | | (class +b +a) | (rel b1) | | (class +C +b) | (rel C1) | | (class +D +a) | (rel D1) `-- now ,--- | (select a1 +C) `--- and ,--- | (select a1 +D) `--- both show me all objects that somehow inherited attribute 'a1', although they only have the same root of the class hierarchy (+a), where the attribute is defined, but do not belong to the same branches of the hierarchy. I do not know what the relations 'rel' are, i.e. which indexes they have and, how these indexes are populated. yes, sorry, its more a kind of PicoLisp pseudocode ... But in general, note that (select a1 +C) reads SELECT a1 from C. This means, you specified no search criterion at all. yes, but my point is I specifiy a class +C and I'm surprised that its superclasses are matched too as well as classes that don't even belong to the same hierarchy tree but only share the same root classe (where a1 is defined). If I search for +Cat with eyes=blue, I would be surprised to find +Tiger or even +Zebra objects in the result list only because attribute eyes is defined in common superclass + Mammals. If you don't give a relation (index) to search for, 'select' tries to find a suitable index by itself by doing some heuristic guesses. This is because the PicoLisp database doesn't enforce any attributes or indexes, and it highly depends on the application how to find which data. And you should keep in mind that 'select' is just a help for debugging. It cannot be used in an application. ok, wasn't aware of this ... For precise searches, use the 'select' and 'db' Pilog queries, or the 'db' and 'collect' Lisp functions. thanks! -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Class inheritance - unexpected behaviour?
Alexander Burger a...@software-lab.de writes: Hi Alex, But in general, note that (select a1 +C) reads SELECT a1 from C. This means, you specified no search criterion at all. yes, but my point is I specifiy a class +C and I'm surprised that its superclasses are matched too as well as classes that don't even belong Yes, I understood that. Unfortunately, 'select' by itself doesn't filter for specific classes (as, for example, the 'db' and 'collect' functions do). It simply gathers objects it can detetct from the '+C' class, by picking some index it believes to be representative (iirc it first looks for some index of class '+Need', as this promises the most hits, and if that doesn't exist it picks the tree with the largest number of entries). So one should not expect too much from the 'select' function. It is just to allow a quick and convenient ad-hoc view on the database. It is a frontend to the 'select' Pilog query, which needs to be programmed explicityly and manually (using 'isa' Pilog clauses in such cases) for a more precise search. Ok, thanks, I wasn't aware of this, and it might be good to give a hint about 'select's limitations in the reference/tutorial, because the way it is described there one would expect equivalent behaviour to sql SELECT, only somehow less powerful and efficient than pilog queries. -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Class inheritance - unexpected behaviour?
On Sun, Sep 29, 2013 at 01:31:06PM +0200, Alexander Burger wrote: Yes, I understood that. Unfortunately, 'select' by itself doesn't filter for specific classes (as, for example, the 'db' and 'collect' functions do). It simply gathers objects it can detetct from the '+C' class, by picking some index it believes to be representative (iirc it first looks for ... frontend to the 'select' Pilog query, which needs to be programmed explicityly and manually (using 'isa' Pilog clauses in such cases) for a more precise search. Hmm .. now that we talk about that, it occurs to me that this 'isa' clause should indeed simply be added to the query-building logic of 'select'. So I went ahead, and extended 'select' a little. It should now behave better like you (and probably everybody else) would expect. Perhaps you can fetch the latest picoLisp.tgz and try again? ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Class inheritance - unexpected behaviour?
Alexander Burger a...@software-lab.de writes: On Sun, Sep 29, 2013 at 01:31:06PM +0200, Alexander Burger wrote: Yes, I understood that. Unfortunately, 'select' by itself doesn't filter for specific classes (as, for example, the 'db' and 'collect' functions do). It simply gathers objects it can detetct from the '+C' class, by picking some index it believes to be representative (iirc it first looks for ... frontend to the 'select' Pilog query, which needs to be programmed explicityly and manually (using 'isa' Pilog clauses in such cases) for a more precise search. Hmm .. now that we talk about that, it occurs to me that this 'isa' clause should indeed simply be added to the query-building logic of 'select'. So I went ahead, and extended 'select' a little. It should now behave better like you (and probably everybody else) would expect. Perhaps you can fetch the latest picoLisp.tgz and try again? a good step, I would say, since the query results I had with (select ..) were very confusing. -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Class inheritance - unexpected behaviour?
Hi List, assume this class hierarchy: ,-- | (class +a) | (rel a1) | | (class +b +a) | (rel b1) | | (class +C +b) | (rel C1) | | (class +D +a) | (rel D1) `-- now ,--- | (select a1 +C) `--- and ,--- | (select a1 +D) `--- both show me all objects that somehow inherited attribute 'a1', although they only have the same root of the class hierarchy (+a), where the attribute is defined, but do not belong to the same branches of the hierarchy. Is that the expected behaviour? From my understanding, only ,--- | (select a1 +a) `--- should show all objects of the hierarchy, the other queries should only show class +D or +C objects repectively. -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
