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).
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.
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
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.
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]
