No, just normal collection/iterator (or cursor) design pattern. The virtual
comes into it when you go n-tier, the full collection resides on a server -
and your Iterator is just a cursor into the full collection, so you only
have to get what you need to see, no matter how big the collection.
As mention by Nic, have a read of the GOF "Design Patterns" book. - although
they do not deal with virtual collections/iterators - but;s just really an
n-tier implementation
Just happens this is easier to do with CORBA. You could do the same with
DCOM. Your iterator can then support search/filter functions, but all the
work is done on the server - and only what you need to see ( visually) ends
up on the client. eg Instant navigation on 1 million item collections. -
sorry scrolling speeds not change. Iterators in Delphi are best implemented
using Interfaced Objects so they die when they go out of scope.
> >This is where I really like Virtual OO Collections and Iterators to solve
> >this kind of problem cleanly (and fast) - goes hand in hand with CORBA.
>
> Erk! Virtual OO Collections? Iterators? And just when I thought I sort
> of understood Interfaces. :) Are these CORBA constructs?
>
> Cheers,
>
> Carl Reynolds Ph: +64-9-4154790
> CJN Technologies Ltd. Fax: +64-9-4154791
> [EMAIL PROTECTED] DDI: +64-9-4154795
> PO Box 302-278, North Harbour, Auckland, New Zealand
> 12 Piermark Drive, North Harbour Estate, Auckland, NZ
> Visit our website at http://www.cjntech.co.nz/
>
> -----Original Message-----
> From: Myles Penlington [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 10, 1999 11:14 AM
> To: Multiple recipients of list delphi
> Subject: RE: [DUG]: Efficient searching in TClientDataSet
>
> Have you tried using SetRange()? Don't know how it works in this case, but
> It **may** be better,
> then it may be okay for locate to still have that line of code, but
> thinking
> about it further the scroll bars on the grid may then give the wrong
> impression ... compromises compromises and more compromises...
>
> This is where I really like Virtual OO Collections and Iterators to solve
> this kind of problem cleanly (and fast) - goes hand in hand with CORBA.
> Myles.
>
>
> > -----Original Message-----
> > From: Carl Reynolds [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, September 10, 1999 10:53 AM
> > To: Multiple recipients of list delphi
> > Subject: RE: [DUG]: Efficient searching in TClientDataSet
> >
> > Thanks Peter (and Myles) for your help, but I guess you're trying to
> solve
> > a different problem. The full story is quite a mouthful, so I've held
> > back from explaining my setup so far - I guess I should go into more
> > detail.
> >
> > Without delving too deeply into why, I have a "listbox" of "customers"
> and
> > an associated "grid" of "orders", and in some cases the orders grid
> might
> > display all, or almost all, orders for ALL customers. I realise that
> this
> > is not often desirable, but it's up to the user. The user does have the
> > option of filtering on the data at any point, but there are valid cases
> > for them wanting to see everything.
> >
> > So, it's a single tier setup, but ClientDataSets are used as they have a
> > lot of useful functionality - for example, constructing indexes on the
> fly
> > so that the data in the grid can be ordered by calculated fields - click
> > on a column and it orders by that column, that sort of thing. In
> > addition, when a query with a very large result set is executed, using a
> > ClientDataSet makes navigating "nicer" in look and feel - once a certain
> > set of records is loaded, browsing among that set is very quick, as
> > opposed to browsing against a query, where paging up a page is just as
> > slow as paging down. This is even without discussing maintenance
> issues.
> >
> > It's this last case, where we have a large result set of all orders for
> > all customers, which interests me. In this case, we want to accept the
> > default ordering of orders grouped by customers. The user always has
> the
> > option of loading in all the records into the ClientDataSet, eg. by
> > dragging the scrollbar on the grid down to the bottom, but under some
> > circumstances this might cause quite a wait. More likely, the user
> might
> > wish to move down to view the orders of a particular customer.
> >
> > It's this moving down in the grid which I'm trying to do as economically
> > as possible - cache the records for all customers down to the customer
> > clicked on, and no more. Unfortunately, the behaviour of
> > ClientDataSet.Locate is to immediately fetch all the records into its
> > cache and then to do a search on the appropriate fields. And moving
> > through the clientdataset record by record, until you find the record
> you
> > want, is very slow indeed. So I ended up modifying
> > ClientDataSet.LocateRecord, as discussed in my last email, and now it
> does
> > do what I want. The code's not perfect (mainly because I fear what
> > GetRecordForKey might actually be doing behind the scenes!) but I
> haven't
> > found a better solution yet and tests so far have worked quite well.
> >
> > What you suggested, and what Myles suggested before you, are totally
> valid
> > if you're doing things in a three tier situation. In that case you'd
> want
> > to avoid the situation that I've described anyway - you would try to
> > insist on quite a stringent filter being applied before ever loading
> down
> > any records to the client. Performance between the middle tier and the
> > database would dwindle into insignificance compared to the
> considerations
> > of data transfer over your WAN. So I appreciate your sensible advice,
> and
> > I don't wish to seem ungrateful, I just didn't explain myself properly!
> > :)
> >
> > Anyway, enough rambling (deep breath :).
> >
> > Incidently, should discussions of Queries and ClientDataSets really be
> > under DUG-DB? Or is that just SQL related stuff?
> >
> > Cheers,
> >
> > Carl Reynolds Ph: +64-9-4154790
> > CJN Technologies Ltd. Fax: +64-9-4154791
> > [EMAIL PROTECTED] DDI: +64-9-4154795
> > PO Box 302-278, North Harbour, Auckland, New Zealand
> > 12 Piermark Drive, North Harbour Estate, Auckland, NZ
> > Visit our website at http://www.cjntech.co.nz/
> >
> > -----Original Message-----
> > From: Peter G Jones [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, September 10, 1999 8:42 PM
> > To: Multiple recipients of list delphi
> > Subject: Re: [DUG]: Efficient searching in TClientDataSet
> >
> > If you are using a cds locally (no server) then presumably you are doing
> a
> >
> > loadfromfile so you will always have all the records in memory. If not,
>
> > then you should do your search on the server via the
> provider.datarequest.
> >
> >
> > >From: Carl Reynolds <[EMAIL PROTECTED]>
> > >Reply-To: [EMAIL PROTECTED]
> > >To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
> > >Subject: [DUG]: Efficient searching in TClientDataSet
> > >Date: Wed, 8 Sep 1999 13:02:32 +1200
> > >
> > >When I do a Locate on a TClientDataSet, it immediately loads all
> > >remaining records into its buffer, ignoring PacketRecords. The same
> > >thing happens when using FindKey or GotoKey. If I don't want to have
> > >all the records loaded automatically (because I have a very large
> result
> > >set), is there a more efficient way to locate a record than to step
> > >through one record at a time, checking each for a match?
> > >
> > >Cheers,
> > >
> > >Carl Reynolds Ph: +64-9-4154790
> > >CJN Technologies Ltd. Fax: +64-9-4154791
> > >[EMAIL PROTECTED] DDI: +64-9-4154795
> > >PO Box 302-278, North Harbour, Auckland, New Zealand
> > >12 Piermark Drive, North Harbour Estate, Auckland, NZ
> > >Visit our website at http://www.cjntech.co.nz/
> > ><< attach3 >>
> >
> > ______________________________________________________
> > Get Your Private, Free Email at http://www.hotmail.com
> >
> --------------------------------------------------------------------------
> > -
> > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> > Website: http://www.delphi.org.nz
> --------------------------------------------------------------------------
> -
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
