RE: Internal storage of nodes

Hi Martin,  thanks for the input.=20

I had a nosebleed idea to start using the 4.0 source instead of the 3.x, =
but
I'm having problems getting the minimum set of libraries together for
standalone mode.  The FAQ looks like the set required for 3.x, and I've =
been
playing around for hours trying to scrape the 4.0 build for stuff that =
might
work.  It looks like it is mostly loading, but the root FS looks empty =
and
there's nothing named 'MDRepositories' registered there.

My current list of jars are as follows:

jmi.jar
jmiutils.jar
mdr.jar
mof.jar
notnow
openide-fs.jar
openide-loaders.jar
openide.jar
org-netbeans-api-mdr.jar
org-netbeans-modules-mdr.jar

The first line of code that I am executing is throwing an NPE in
getDefaultRepository():

  MDRepository repository =3D =
MDRManager.getDefault().getDefaultRepository();

Any ideas on what I am missing?

thanks!

-b

> -----Original Message-----
> From: Martin Matula [mailto:[email protected]]
> Sent: Tuesday, October 12, 2004 4:56 PM
> To: [email protected]
> Subject: Re: [mdr-dev] Internal storage of nodes
>=20
>=20
> Brian,
> if you are using repository in a usual way (with=20
> memory/b-tree storage),=20
> DeferredObjects should never be used, externalObjects should=20
> always be=20
> null, so getExternal should take no time. All the objects in=20
> the storage=20
> are subclasses of StorableBaseObject. MdrStorage.getObject() reads=20
> object from the storage based on its MOFID.
> refAllOfType call delegates to StorableClass.allObjects(true), which=20
> creates a lazy collection over a storage index (we store a separate=20
> index in the storage that maps a class to all of its instances).
> Hopefuly this helps. I am still not sure if I understand what exactly=20
> you need.
> Martin
>=20
> Brian Topping wrote:
>=20
> >Hi Martin,
> >
> >I'd like to use this in a tool that I have already built=20
> that uses the
> >MDRepository interface.  The storage would would be=20
> transient memory storage
> >only. =20
> >
> >In the end, my primary goal is not really a focus on the=20
> storage, but an
> >effort to get to the source of where nodes come from in an=20
> extant model, such
> >as when a collection is returned from a refAllOfType call. =20
> It seems like
> >these collections always go through getExternal, but I=20
> realize I might be
> >looking in the very wrong place for things ;-)
> >
> >Thanks!
> >
> >Brian
> >
> > =20
> >
> >>-----Original Message-----
> >>From: Martin Matula [mailto:[email protected]]
> >>Sent: Tuesday, October 12, 2004 3:55 PM
> >>To: [email protected]
> >>Subject: Re: [mdr-dev] Internal storage of nodes
> >>
> >>
> >>Hi Brian,
> >>in what context do you want to measure this? Are you using MDR as a=20
> >>standalone tool or do you refer to its usage in JavaCore module?
> >>Martin
> >>
> >>Brian Topping wrote:
> >>
> >>   =20
> >>
> >>>Hi list,
> >>>
> >>>I'm experimenting with some code in NBR and was wondering if=20
> >>>     =20
> >>>
> >>I could confirm
> >>   =20
> >>
> >>>some of my findings or get some alternate suggestions. =20
> >>>
> >>>I'm trying to find bottleneck points in the code for objects=20
> >>>     =20
> >>>
> >>in a repository.
> >>   =20
> >>
> >>>I'd like to add some experimental code to audit them as they=20
> >>>     =20
> >>>
> >>go in or out of
> >>   =20
> >>
> >>>storage.  It seems like persistent storage of objects is all=20
> >>>     =20
> >>>
> >>done by mofID
> >>   =20
> >>
> >>>via DeferredObjects, is that so?  Then it seems that
> >>>registerExternal/removeExternal/getExternal in MdrStorage=20
> >>>     =20
> >>>
> >>are going to be
> >>   =20
> >>
> >>>bottlenecks, that I should be able to audit everything that=20
> >>>     =20
> >>>
> >>is created or
> >>   =20
> >>
> >>>read from there.
> >>>
> >>>If this isn't the case, is there some minimal set of points=20
> >>>     =20
> >>>
> >>that I can
> >>   =20
> >>
> >>>intercept where objects in the repository are sent after=20
> >>>     =20
> >>>
> >>they are created?
> >>   =20
> >>
> >>>Thanks!
> >>>
> >>>Brian
> >>>=20
> >>>
> >>>     =20
> >>>
> >>   =20
> >>
> >
> > =20
> >
>=20
>=20
>=20