Hi Andrea (I am not at the office so this message may not go trough to the <dspace-devel> list: please reply with a copy of this if you find this message worthwhile),
From my point of view, we have an even worse problem: not enough distinction between "object reference" and "object instantiation". In a bibliographic database, you can very often manipulate TreeSet of Keys (TreeSet of integers in DSpace case) for which you can have very fast boolean unions, intersections and exclusions. You can even use sparse IntegerSet which compress the set even more than a boolean array. This is not available in DSpace: it is one of the major reason this application does not scale up.
From my point of view "SparseIntegerSet" should be the prefered representation of any DSpace Object Set manipulated within DSpace with DSpaceObject instantiation delayed as much as possible.
The problem with this are sorted sets: sorting must be delayed but as to be done at a moment or another... and kept from one transaction to the next. Here, an Integer array (or list) may be the best representation. And very partial instantiation of DSpaceObject (only the necessary sort fields) must be done by the sort function...
I more and more believe that DSpace will need a "scale-up" task force. I am not sure that the move towards Cocoon (Manakin) will help on performance issue...
Have a nice day!
Christophe Dupriez

Andrea Bollini <bollini@cilea.it> a écrit :
Hi, many methods of core class return Array of specific DSpaceObject,
if we are going to use the generics should be right switch to return
This change will provide a more clear&friendly API but is not simple to
make in a cheap way. Do we want provide it for DSpace 1.5 or later

James Rutherford ha scritto:
> Hi all,
> Now that trunk uses jdk 1.5, it might be a good time to do a little
> refactoring of the code to take advantage of some new language features.
> In particular (but only where appropriate):
> * using varargs instead of several near-identical functions (already
> done in DatabaseManager.java). this will require some care to make
> sure that arguments are non-null.
> * annotations: i'd like to see addDC / getDC / clearDC from Item get
> @Deprecated, if nothing else (between them, they are still referenced
> 58 times!). i'm sure there are other places where we could benefit
> from compile time warnings as well.
> * generics: adding compile-time type safety is surely a Good Thing.
> * eliminate Iterators: with generics + the new for/in loop, we could
> probably tidy up lots of the code by getting rid of Iterators (i
> don't think we use Iterator.remove() that much anyway).
> I know this isn't everything new we have available in jdk 1.5, but (IMO)
> they have the lowest barrier to incorporation. For instance, it might be
> nice to eventually factor out org.dspace.core.Constants into a bunch of
> enums, or to switch to using static imports in various places, but
> they don't seem like "phase 1" actions, if they are indeed desirable at
> all.
> thoughts?
> Jim

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Dspace-devel mailing list

Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses.