Re: Fwd: Using a non-existent collection inside a query
hi edson,
[EMAIL PROTECTED] wrote:
hi edson,
frankly, i'm still confused...
Sorry... I think I don't have sufficient english skills to make more clear...
i understand that collection-proxies do not seem to help because of the
way you built your gui :(
Thanks, I think you had some experiences (some good, some bad) with swing too... But
that's not our point, right ;-)
when you say the relationship does not exist, does this mean that it's
not defined in the repository ?
Yes, I mean that this is not defined in repository. Neither the collection-descriptor,
neither the field used when querying.
i saw the sample code you posted some days ago. now it's clear how you do it.
what do you mean by mounting the query ?
Imagine the object:
public class Customer {
public Integer id;
public String name;
}
Now I load some class that will notify (internally, in my app) that a new table is
avaliable
in database (the documents table), and I can make queries by the document number. But I
don't have a document neither documentNumber in Customer class.
To query I must do
Criteria c = new Criteria();
c.addEqualTo(document.documentNumber, 12345);
But OJB will throw exception: where is no document field in Customer. So I add
dinamically a
document field as an collection descriptor. Uau, OJB now queries the database! Fine
that's
all I want.
But, when I tried to store any Customer object, OJB throw an exception saying that
there is
no document field. Even if I use proxies=true (or not), lazy=true (or not),
auto-update=false (or not) and so on. Nothing works. Always exception.
ojb needs this field (better: the collection referenced by this field) to handle
the m:n-implementors in case of an m:n-relationship.
I've detected that the problem is because OJB is trying to set key fields in
referenced
objects (including my document collection - that doesn't exists at all, is just an
artifact
to make queries) - before storing...
afaik this should only be done if getCascadeStore() is true. imo the method
storeCollections() needs some refactoring to separate handling of
m:n-implementors, but that's another issue.
what other parts of ojb did you need to modify to achieve this behaviour ?
None. Just that if does the job. I had think a lot about this, and I get the
conclusion that
OJB should not set keys in referenced object when auto-update=false, right? Or not?
As long as I don't want do change any default behavior of OJB, I've created the virtual
attribute, and used it...
jakob
Thanks again,
Edson Richter
-
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]
Re: Fwd: Using a non-existent collection inside a query
i saw the sample code you posted some days ago. now it's clear how you do it. The first step ;-) ojb needs this field (better: the collection referenced by this field) to handle the m:n-implementors in case of an m:n-relationship. That's just the case. If I use the artifact of virtual, the real field is no needed. It will never be read neither writeen to database. Just referenced when querying the database. afaik this should only be done if getCascadeStore() is true. imo the method storeCollections() needs some refactoring to separate handling of m:n-implementors, but that's another issue. The setting of the keys in referenced objects are occurring always. That why I need to put the line with if command in PersistenceBrokerImpl storeCollections method. I've not tried this with M:N, but sometime in the future I will check it (as far as the users get accostumed with this kind of facility, they wants more!). jakob Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
hi edson, [EMAIL PROTECTED] wrote: i saw the sample code you posted some days ago. now it's clear how you do it. The first step ;-) ojb needs this field (better: the collection referenced by this field) to handle the m:n-implementors in case of an m:n-relationship. That's just the case. If I use the artifact of virtual, the real field is no needed. It will never be read neither writeen to database. Just referenced when querying the database. afaik this should only be done if getCascadeStore() is true. imo the method storeCollections() needs some refactoring to separate handling of m:n-implementors, but that's another issue. The setting of the keys in referenced objects are occurring always. That why I need to put the line with if command in PersistenceBrokerImpl storeCollections method. i do not see where this happens ? jakob I've not tried this with M:N, but sometime in the future I will check it (as far as the users get accostumed with this kind of facility, they wants more!). jakob Edson Richter - 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]
Re: Fwd: Using a non-existent collection inside a query
i do not see where this happens ?
Here (note: the if(!true.equals( bellow is in my patched version of OJB that is
working
fine):
...
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);
}
}
...
Edson Richter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
Interesting is that this code is right (will only occur if cds.getCascadeStore()
returns true):
private void storeCollectionObject(CollectionDescriptor cds, Object otherObject)
{
// if cascade store: store associated object
if (cds.getCascadeStore())
{
store(otherObject);
}
else
{
if(logger.isEnabledFor(Logger.INFO)) logger.info(Cascade store for this
collection-descriptor ( + cds.getAttributeName()
+ ) was set to false.);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
Really, executing again withou my patch, I've seen that is not the keys, but the field it self. Sorry... The line getting in trouble is Object col = cds.getPersistentField().get(obj); because there is no persistent field at all. I'm a bit lost in too much code, techs, newbie programmers, and so on here... I think 1) if we use getCascadeDelete != true early, we can have trouble with M:N relationships; 2) if we use later, we get a non existent property exception because the field just don't exist in the bean. As far as I can see, this is the way the virtual attribute affect the OJB behavior. Thanks, Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
hi edson,
frankly, i'm still confused...
Sorry... I think I don't have sufficient english skills to make more clear...
i understand that collection-proxies do not seem to help because of the
way you built your gui :(
Thanks, I think you had some experiences (some good, some bad) with swing too... But
that's not our point, right ;-)
when you say the relationship does not exist, does this mean that it's
not defined in the repository ?
Yes, I mean that this is not defined in repository. Neither the collection-descriptor,
neither the field used when querying.
what do you mean by mounting the query ?
Imagine the object:
public class Customer {
public Integer id;
public String name;
}
Now I load some class that will notify (internally, in my app) that a new table is
avaliable
in database (the documents table), and I can make queries by the document number. But I
don't have a document neither documentNumber in Customer class.
To query I must do
Criteria c = new Criteria();
c.addEqualTo(document.documentNumber, 12345);
But OJB will throw exception: where is no document field in Customer. So I add
dinamically a
document field as an collection descriptor. Uau, OJB now queries the database! Fine
that's
all I want.
But, when I tried to store any Customer object, OJB throw an exception saying that
there is
no document field. Even if I use proxies=true (or not), lazy=true (or not),
auto-update=false (or not) and so on. Nothing works. Always exception.
I've detected that the problem is because OJB is trying to set key fields in referenced
objects (including my document collection - that doesn't exists at all, is just an
artifact
to make queries) - before storing...
what other parts of ojb did you need to modify to achieve this behaviour ?
None. Just that if does the job. I had think a lot about this, and I get the
conclusion that
OJB should not set keys in referenced object when auto-update=false, right? Or not?
As long as I don't want do change any default behavior of OJB, I've created the virtual
attribute, and used it...
Thanks again,
Edson Richter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
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]
Re: Fwd: Using a non-existent collection inside a query
Hi Edson,
do you have a test case to show the problem? This would be helpful to
test your new feature or to find another solution.
regards,
Armin
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!
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]
