You may also be interested in the StateManager.getDirty() method, which returns a BitSet corresponding to the entries in StateManager.getMetaData().getFields(). The BitSet identifies which fields in a given object are modified.
On top of that, you could also take advantage of StateManager.getFlushed(), which returns another BitSet indicating which fields have already been flushed. Combining the two, you can compute which fields are dirty and unflushed; in a pre-flush callback, these are the fields that have been mutated since the last time flush() was invoked (directly or indirectly). Speaking of incremental flushing, is Compass transactional? IOW, is it possible to periodically (at flush() time) update Compass with mutations, and then only make the changes visible outside the current transactional scope at commit time? If so, it'd be interesting to also explore how we could hook up OpenJPA savepoints (when available). If not, then we should make sure we figure out what the memory implications are of using Compass + OpenJPA incremental flushes + large transactions. OpenJPA has features designed for optimizing memory handling in large transactions; Compass/OpenJPA work could probably dovetail nicely into some or all of these existing integration points. -Patrick -- Patrick Linskey BEA Systems, Inc. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -----Original Message----- > From: Shay Banon [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 02, 2007 12:22 AM > To: open-jpa-dev@incubator.apache.org > Subject: RE: Getting all the ClassMetaDatas > > > Compass provides two main features with JPA: Mirroring and Indexing. > Mirroring mirrors changes made through the JPA API into the > search engine > (through lifecycle listeners), and Indexing allows to > automatically index > all your database using both the JPA and Searchable classes. > The indexing > process requires to fetch or intersect with the current > classes that are > persistent. > > The indexing process fetches all the indexable entities and > then iterate (in > parallel) them in order to index them into the search engine. So, I am > guessing that if classes are introduced to JPA at runtime, > the user would > need to pre-register them with OpenJPA (when using the > OpenJPA plugin in > order to locate persistent entities) in one of the ways that OpenJPA > provides. > > The user could, if only Annotations are used, to use the > default entities > locator that comes with Compass, which basically check for the @Entity > annotation. The only main drawback with this one is that it > does not support > xml or other mechanism to introduce new mappings for classes. > > -Shay > > > Patrick Linskey wrote: > > > > Is there any reason why you need to eagerly get information about > > classes to process? In general, as you've noticed, OpenJPA > does allow > > dynamic registration of persistent types. One possibility > would be to > > declare that in order to use Compass searching with > OpenJPA, one must > > provide a static list of classes (or tell OpenJPA to > compute a static > > list of classes), using one of the options that Marc pointed out > > earlier. Alternately, you could potentially just register > the right type > > of listener with OpenJPA and do whatever initialization is necessary > > lazily as new classes are encountered via the callbacks. > > > > -Patrick > > > > -- > > Patrick Linskey > > BEA Systems, Inc. > > > > > ______________________________________________________________ > _________ > > Notice: This email message, together with any attachments, > may contain > > information of BEA Systems, Inc., its subsidiaries and > affiliated > > entities, that may be confidential, proprietary, > copyrighted and/or > > legally privileged, and is intended solely for the use of > the individual > > or entity named in this message. If you are not the > intended recipient, > > and have received this message in error, please immediately > return this > > by email and then delete it. > > > >> -----Original Message----- > >> From: Shay Banon [mailto:[EMAIL PROTECTED] > >> Sent: Monday, January 01, 2007 1:11 PM > >> To: open-jpa-dev@incubator.apache.org > >> Subject: Getting all the ClassMetaDatas > >> > >> > >> Hi, > >> > >> First, I hope that this is the correct forum for posting > >> questions, so > >> sorry if it isn't. > >> > >> I have an external list of classes that I would like to match > >> against the > >> persistent classes that are defined/identified by OpenJPA. I > >> would really > >> like to get the ClassMetaData for each one, since it has a lot of > >> information that I could use. This intersection happens after the > >> EntityManagerFactory has been created. > >> > >> I have tried using:ClassMetaData[] classMetaDatas = > >> > emf.getConfiguration().getMetaDataRepositoryInstance().getMetaDatas(); > >> > >> But it seems like the meta data repository and ClassMetaData > >> information are > >> lazily loaded (i.e. when some operation is performed on a > Class, the > >> relevant meta data is fetched if not found in cache). So, > >> what I get is an > >> empty array (even though I can see the OpenJPA identified the > >> classes). > >> > >> I wonder how I would be able to get all the class meta data? > >> > >> Something that I was thinking about is since I have the list > >> of classes that > >> I would like to check if they are persistent, I could call: > >> getMetaData(Class cls, ClassLoader envLoader, boolean > mustExist), with > >> Thread context class loader and false in mustExists. I am > >> guessing that it > >> will load the ClassMetaData if not found. My main problem > here is that > >> OpenJPA might be configured with a different class loader > (though it > >> defaults to the thread context one). > >> > >> Any suggestions? > >> > >> p.s. > >> > >> I am the author of Compass, so once I have this nailed down, > >> we will have > >> Search capabilities to OpenJPA ;) > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/Getting-all-the-ClassMetaDatas-tf2905426 > > .html#a8116958 > >> Sent from the open-jpa-dev mailing list archive at Nabble.com. > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Getting-all-the-ClassMetaDatas-tf2905426 .html#a8121024 > Sent from the open-jpa-dev mailing list archive at Nabble.com. > >
