On Wednesday 12 November 2008 00:44, xor wrote:
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED] 
> > > @@ -178,8 +178,20 @@
> > >   public synchronized Iterator<FMSMessage> threadIterator(final
> > FMSOwnIdentity identity) {
> > >           return new Iterator<FMSMessage>() {
> > >                   private final FMSOwnIdentity mIdentity 
> > = identity;
> > > -                 private Iterator<FMSMessage> iter = 
> > self.mThreads.iterator();
> > > -                 private FMSMessage next = 
> > iter.hasNext() ? iter.next() : null;
> > > +                 private final ObjectSet<FMSMessage> mMessages;
> > > +                 private final Iterator<FMSMessage> iter;
> > > +                 private FMSMessage next;
> > > +                  
> > > +                 {
> > > +                         Query q = db.query();
> > > +                         q.constrain(FMSMessage.class);
> > > +                         
> > > q.descend("mBoards").constrain(mName); /* FIXME: mBoards is an array. 
> > > Does constrain() check whether it contains the element mName? */
> > 
> > No.
> 
> This is bad news! It means that we will have to store a per board message
> list in some way. Any ideas on how to do it efficiently using db4o as much 
> as possible?

Hmmm... I may be wrong here... I dunno how indexes would be used in such a 
case, I think if you use QBE (and therefore presumably constrain) you can do 
it...
> 
> Well actually its good news: Even if that query was possible, it
> would not be efficient anyway. 

Dunno whether it uses an index for such things.

> The only efficient way of retrieving 
> messages per-board is to store a per-board list of messages of course.

Or use a tag object (struct with the board and the message) to connect them.

> As you know I had done that with LinkedLists and Hashtables in the past
> but changed it to this simple db4o query for the sake of using db4o.

These will have to loaded in their entirety, but that's probably acceptable in 
this case - the number of messages on a board won't be vast.
>  
> > > +                         q.descend("mParentURI").constrain(null);
> > 
> > You should add .identity(). However, in my experience 
> > constraining to null doesn't work, or works but pulls in 
> > every object rather than using the index.
> 
> This sucks. In my current design of the FMSMessage class, a thread is 
> defined by not having a parent URI. It means that I will have to
> add booleans everywhere where I use null as a special information.
> 
> Is this a db4o bug?

It works but it doesn't use the index, in my experience:
http://tracker.db4o.com/browse/COR-1446
> 
> > 
> > > +                         q.orderDescending();
> > 
> > Descending on which field?
> 
> I had already fixed that. We sort by date.

Attachment: pgpUv3z3HBf0O.pgp
Description: PGP signature

_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to