frankly, i'm still confused...
[EMAIL PROTECTED] wrote:
Well, first of all, I already use collection proxies. Second, because I don't have fields (in the object model) relating them... More: the customer object has (today) 10 collections proxies, and 5 references and OJB is being so slow at every collection I add (note, I use Swing, so Proxy doesn't have exatcly same good effect than in JSP - When you have a multi-tabbed pane in JSP, each tab is a page that will read only their info. In swing, the worker thread will need to show info for all combo, lists, and so on, so it will materialize every thing).
i understand that collection-proxies do not seem to help because of the way you built your gui :(
Think in this way: my customer object at design time knows nothing about how many relations it can have at runtime (neinhter have the methods to access this information). So, in the customer object, I don't have methods to set these collections - BUT I need to give my user a chance (at runtime) to query customers based on these data. You will ask: but if you don't have a method to access the information, why you need it? The answer is: because my UI will be notified of the new object, then will notify a network of listeners, that will know "oh, well, there is a new customer here", and will load their own information.
Let's make an example:
The system is running at a School (one type of client we work). In a school, each customer (the student) have an application (or course registration if you prefer). In runtime, an user could query for customers applyied to some course.
Now, the system is running at a factory. In a factory, each customer have customized products. A user could query for customers that buy some type of product.
The relation between customer and courses (M:N) exists in the school, but doesn't exists in the factory. And the relation between customer and products (1:N) exists in the factory, but not in school.
when you say the relationship does not exist, does this mean that it's not defined in the repository ?
It's a kind of extreme generic application, where the modules are loaded according to the user profile.
If this still not clear, let me make you know that I have a complicated Object broker layer over OJB (that is my Persistence Broker layer), and over this Object Broker I have a Services layer, and over this I have a MVC layer based on Swing. When I load a module, the Swing layer is notified that new ways to search objects are avaliable, the Services make avaliable the new criterias, and the OJB is responsible to mount these queries. It's an
what do you mean by mounting the query ?
ununsual use for OJB (may be), but, as I stated before, it's a large and complicated, multi-threaded, swing application.
Well, if this affects too much OJB, I don't want to be boring you all with crazy details about a crazy way of work. I'll just apply my patch to source in every new version of OJB, and all will be fine.
what other parts of ojb did you need to modify to achieve this behaviour ?
jakob
Thanks for attention.
Edson Richter
Edson Carlos Ericksson Richter wrote:
(sorry, was a "momentary lapse of reason" when I clicked the send button).
Hi!
I'm facing a problem: I've a nice piece of sofware that load modules at runtime. Mostly, each module has their own .xml file with necessary configuration. So, there are no problem here.
But imagine that I've a customer_repository.xml, that references a quite large table (let's say 100.000, to take easy to imagine). If each customer has 1:n fone numbers, 1:n address, 1:documents, 1:n anything else, and so on, I need to make use of the Proxies, or I'll crash server (or workstation) memory (even with 512Mb). Ok, that's fine. But when I open my Swing UI, every JTable, JList, JCombo and so on insists in materialize every 1:N mapping in .XML file. So, I have a very large time when materializing objects (to materialize one single person I take near 2 seconds... A user "clicking away" in the machine think that this is a "long time" to wait for a "simple navigation" in records!
hi edson,
why don't you use a CollectionProxy for each of those 1:n collections ?
jakob
So I started to think in a solution where the collection is used when mounting the WHERE clauses, but not when loading/writing objects to database. And I started with API to create on-the-fly collections.
All worked well, as I imagined (I can add the collection and play with fine), but the first time I've attempted to write one customer object I get that some method X was not found in object Y... And if I put the method X, I get "column Z not in table" from my database. So, the OJB is trying to persist the collection (even if I set the auto retrieve, auto update and auto delete as false). Since I thinked in terms of virtual collection (that can exists or not), and the queries and materialization are working fine, I started to imagine the I need to make a patch to guarantee that the collection will never be stored. Then, I've added a attribute "virtual" that, when receives true, is ignored by "storeCollections" loop.
My question is: can this be added to core OJB distribution, or I'll always need to patch my own versions of OJB?
The method was modified on PersistenceBrokerImpl is (just the if(!"true".equals(cds.getAttribute("virtual"))) was added, and the respective block start and end), and doesn't affect nobody else than who wanna use these "virtual collection" way of work (I can send the code sample where I'm using this, if you want):
private void storeCollections(Object obj, Vector vecCds) throws PersistenceBrokerException { // get all members of obj that are collections and store all their elements Iterator i = vecCds.iterator(); while (i.hasNext()) { CollectionDescriptor cds = (CollectionDescriptor) i.next(); if(!"true".equals(cds.getAttribute("virtual"))) { Object col = cds.getPersistentField().get(obj); Collection currentMtoNKeys = null; if (col == null) { if (cds.isMtoNRelation()) { deleteMtoNImplementor(cds, obj); } } else { // MBAIRD // if the collection is a collectionproxy and it's not already loaded // no need to store it. if (col instanceof CollectionProxy && !((CollectionProxy) col).isLoaded()) { continue; } if (cds.isMtoNRelation()) { currentMtoNKeys = getMtoNImplementor(cds, obj); // delete unused m:n implementors deleteMtoNImplementor(cds, obj, (Collection)col, currentMtoNKeys); } Iterator colIterator; if (col instanceof ManageableCollection) { colIterator = ((ManageableCollection) col).ojbIterator(); } else if (col instanceof Collection) { colIterator = ((Collection) col).iterator(); } else if (col.getClass().isArray()) { colIterator = new ArrayIterator(col); } else { throw new OJBRuntimeException( col.getClass() + " can not be managed by OJB, use Array, Collection or ManageableCollection instead !"); } while (colIterator.hasNext()) { Object otherObj = colIterator.next(); // for m:n mapped collections store association implementing entries if (cds.isMtoNRelation()) { // 1. Store depended upon object first to avoid FK violation storeCollectionObject(cds, otherObj); // 2. Store indirection record // BRJ: this could cause integrity problems because // obj may not be stored depending on auto-update storeMtoNImplementor(cds, obj, otherObj, currentMtoNKeys); } // for 1:n mapped collection assert proper fk assignment else { if (cds.getCascadeStore()) { // BRJ: do not assign fk if not required // to avoid materialization of proxy assertFkAssignment(otherObj, obj, cds); } storeCollectionObject(cds, otherObj); } } // invoke callback on collection if (col instanceof ManageableCollection) { ((ManageableCollection) col).afterStore(this); } } } } }
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.554 / Virus Database: 346 - Release Date: 20/12/2003
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
