Lazy associations

Question

We understand that FDS supports lazy associations, but the
documentation is unclear about whether it's necessary and in what
manner to partially initialize an array which is not empty but in
the "lazy" state, as opposed to the fully initialized state, and
the empty state.
We are using the Java adapter, so our application is
responsible for how data comes out of the DAO layer.
Any information would be appreciated - thank you.

Answer 1

If you are returning collections where the set of ids is too
large to be returned all at once, you should implement that
relationship using a fill method, not using an association
property. In this case, usually the id of the related item is at
least one of the fill parameters. For example, I have reimplemented
the crm demo in beta 2 so that it returns the list of employees for
a given company as a fill method which takes the company id as a
parameter. This allows you to either use fill parameters to
demarcate pages (i.e. you might have a page number parameter), or
to use flex's built in paging support.
Currently in FDMS, the fill method must return all of the
items to be returned in the fill so if the fill is too large to be
returned as a single result set even for the server, you need to
split it up using fill parameters to control the paging (in other
words, you have to do paging yourself and can't use fdms' builtin
paging support to do this automatically). Though we wanted to
support complete 'client controlled' paging all the way through to
the database, it is fairly challenging to keep a list sync'd
between two clients when you do not even know the complete contents
of the list, how big it is, the ways the client can access pages
etc. We might be able to support a variant of the fill method which
implements paging only for the auto-sync-enabled=false case (where
you are not sync'ing changes between clients) but it sounds like
you need clients to be kept in sync even on these large lists as
they change?
I think that in the general case of client controlled but
server performed filtering and sorting, you pass in the sorting and
filtering criteria (including ranges) via fill parameters. The
server performs the operation and returns that set of items so you
get an ArrayCollection on the client which contains just a page of
data at a time. If you want to implement a virtual array collection
on top of that which represents the entire data set that will then
make fill calls as needed to fetch pages you'd have to do that
yourself in action script code. Another strategy would be to make
the paging controls explicit in the UI (ie. have a next page button
which fetches the next page instead of scrolling through the list)
and that would make it easier.
In terms of caching, when you have auto-sync-enabled set to
true, FDMS must at least cache the graph of ids of all of the
managed items by all active managed clients. By default, it caches
the items too but you can turn this off with
<cache-items>false</cache-items>. If you need to keep
your clients up-to-date with changes performed by code that
accesses the DB directly or is just not going through flex, you can
use the 'server push api' to tell flex about these changes, or just
use this api to periodically refresh your clients. If your clients
do not need to be made aware of these changes, you can just let
them drift out of sync and use the conflict detection facilities to
deal with stale updates. If you are using timestamps for your
version numbers, you could probably implement a "get me a list of
everything that has changed" query in a scheduled task which then
uses the server push api to keep clients in sync.