Re: Reading objects
On Sat, Apr 14, 2012 at 09:59:51PM +0700, Henrik Sarvell wrote: > Basically because I wanted to be able to list the objects without > knowing about any refs or keys but I suppose I can introspect and just > do a collect by the first one I find for the given class. Because as > you said, any useful structures usually have them. Perhaps you might take a look at the 'select' function in "lib/sq.l" http://software-lab.de/doc/refS.html#select It is an interactive function, and thus not useful in itself for your purpose, but it uses some heuristics to detect the proper index(es). Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Reading objects
Basically because I wanted to be able to list the objects without knowing about any refs or keys but I suppose I can introspect and just do a collect by the first one I find for the given class. Because as you said, any useful structures usually have them. On Sat, Apr 14, 2012 at 7:11 PM, Alexander Burger wrote: > Hi Henrik, > >> Thanks, I gather then that there will never be millions of relations >> etc in #1 then? > > No, it is perfectly all right to have millions or billions of entities > in file 1. It is just not a good idea (in general) to access them > sequentially. > > That's why I mentioned that 'seq' is not intended for "normal" DB > operations. If entities need to be searched for sequentially, you don't > need a DB after all. Normally, you have higher-order structures like > indexes or lists which allow direct application-specific access to the > entities. > > >> If so I might just create some dummy entity (that I will never have to >> scan/seq) and put it there. > > For what purpose? I think I don't understand your intention in this > specific case yet. > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Reading objects
Hi Henrik, > Thanks, I gather then that there will never be millions of relations > etc in #1 then? No, it is perfectly all right to have millions or billions of entities in file 1. It is just not a good idea (in general) to access them sequentially. That's why I mentioned that 'seq' is not intended for "normal" DB operations. If entities need to be searched for sequentially, you don't need a DB after all. Normally, you have higher-order structures like indexes or lists which allow direct application-specific access to the entities. > If so I might just create some dummy entity (that I will never have to > scan/seq) and put it there. For what purpose? I think I don't understand your intention in this specific case yet. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Reading objects
Thanks, I gather then that there will never be millions of relations etc in #1 then? If so I might just create some dummy entity (that I will never have to scan/seq) and put it there. On Sat, Apr 14, 2012 at 3:15 PM, Alexander Burger wrote: > On Sat, Apr 14, 2012 at 09:47:26AM +0200, Alexander Burger wrote: >> I always use the following pattern in such cases: >> >> (for (This (seq (db: +User)) This (seq This)) >> (when (isa '+User This) >> (doSomething This) ) ) > > BTW, I would be cautious using 'seq' in application code. It is a rather > low-level access to the database objects, and more typically used in > debug and maintenance code. > > If you want to use the above in a more generic way, you might consider > to use (isa '+Entity This) instead of a specific class. > > > Also, you might need to filter for other things too. For example, to > avoid collecting objects marked as obsolete (with the 'lose>' message), > you would do > > (for (This (seq (db: +User)) This (seq This)) > (and > (isa '+Cls This) > (not (: T)) > (doSomething This) ) ) > > as the 'T' property is set when 'lose>'ing objects. > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Reading objects
On Sat, Apr 14, 2012 at 09:47:26AM +0200, Alexander Burger wrote: > I always use the following pattern in such cases: > >(for (This (seq (db: +User)) This (seq This)) > (when (isa '+User This) > (doSomething This) ) ) BTW, I would be cautious using 'seq' in application code. It is a rather low-level access to the database objects, and more typically used in debug and maintenance code. If you want to use the above in a more generic way, you might consider to use (isa '+Entity This) instead of a specific class. Also, you might need to filter for other things too. For example, to avoid collecting objects marked as obsolete (with the 'lose>' message), you would do (for (This (seq (db: +User)) This (seq This)) (and (isa '+Cls This) (not (: T)) (doSomething This) ) ) as the 'T' property is set when 'lose>'ing objects. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Reading objects
Hi Henrik,
> of a heavier web framework than pl-web and for the read part I need to
> be able to walk through all objects of a certain type regardless of
> what kind of keys and references they might or might not have.
> ...
> (dbs
>(4 +User) #1
> ...
> (dm read> ()
>(let Cur (car (get This 'Dbf))
> (make
> (while (setq Cur (seq Cur))
> (link Cur) ) ) ) )
OK, you are on the right track. 'seq' is the way to access all objects
in a given file independent from indexes and references.
I always use the following pattern in such cases:
(for (This (seq (db: +User)) This (seq This))
(when (isa '+User This)
(doSomething This) ) )
> The above works but not for +User (I assume because they are in the
> first file), trying (read> '+User) will still return some relations.
Right. The reason is that the first DB file contains also other,
non-entity objects holding meta informations. Most notably the root
object (in '*DB')
> {1} NIL
>+Menu {7}
>+Block {6}
>+Page {5}
>+User {3}
and also the the bases of indexes like
> {5} NIL
>parent (5 . {G3})
>path (6 . {G2})
>name (6 . {G1})
> Of course I could filter them but there must be a better/more
> efficient way?
A filter is necessary here. But I would not worry, a simple 'isa' as in
my example above won't introduce a noticeable overhead.
(dbs
...
(3 (+Page name path parent))#8
...
> (rel name (+Ref +String))
> (rel path (+Key +String))
> (rel parent (+Ref +Link) NIL (+Page))
>
> I would have expected those refs and key to end up in file #8?
Correct. But while the _nodes_ of those index trees do indeed reside in
#8, the _base_ still is in an external symbol in #1.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
