Using alternate key instead of primary key when relating an class descriptor with a collection descriptor
Hello.
I've searched the gmane archives, but I was unable to find any messages
related to my question.
Suppose that I have the following classes...
public class User {
private Integer id; // primary key field
private String username; // alternate key field
private Collection userRoles; // collection of UserRole objects related
by username
};
public class UserRole {
private String username; // foreign key
private String rolename;
}
...and I wanted to relate User and UserRole in a repository mapping based
on the equality of the username fields in both User and UserRole. Can this
exact schema be handled through a repository mapping? (Does
fk-pointing-to-this-class work without using an indirection-table? Is
there an alternative?)
Most of the rest of the data model in the application uses User.id as a
foreign key, so we can't easily change the primary key of the user table.
The UserRole fields were chosen for compatibility with Tomcat
JDBCRealm-like declarative security implementations.
The only way that I can see to work around this problem is to duplicate the
User.id field in the UserRole table, along with the username.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using alternate key instead of primary key when relating an class descriptor with a collection descriptor
I'll have a look at the documentation; thanks for the link.
Robert r. Sanders [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Look at:
doc/docu/guides/basic-technique.html#Support+for+Non-Decomposed+m%3An+Mappings
in the OJB documentation. I think I was able to get something along
these lines to work in a test (pre- 1.0). I think it would be relatively
straight forward for you to implement a test and see if it works; I
would simpy mark the username as a key, and then try it. Changes to the
OJB meta-data that prevent this would be my main concern
Sean Dockery wrote:
Hello.
I've searched the gmane archives, but I was unable to find any messages
related to my question.
Suppose that I have the following classes...
public class User {
private Integer id; // primary key field
private String username; // alternate key field
private Collection userRoles; // collection of UserRole objects
related by username
};
public class UserRole {
private String username; // foreign key
private String rolename;
}
...and I wanted to relate User and UserRole in a repository mapping based
on the equality of the username fields in both User and UserRole. Can
this exact schema be handled through a repository mapping? (Does
fk-pointing-to-this-class work without using an indirection-table? Is
there an alternative?)
Most of the rest of the data model in the application uses User.id as a
foreign key, so we can't easily change the primary key of the user table.
The UserRole fields were chosen for compatibility with Tomcat
JDBCRealm-like declarative security implementations.
The only way that I can see to work around this problem is to duplicate
the User.id field in the UserRole table, along with the username.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Robert r. Sanders
Chief Technologist
iPOV
www.ipov.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using alternate key instead of primary key when relating an class descriptor with a collection descriptor
I don't think what you want is possible because it goes against concepts
of row indentity and referential integrity.
Sorry, but that is incorrect.
There is no restriction on having more than one key that can uniquely
identify a row. All of the keys which can serve to identify a row are
called candidate keys. From the candidate keys, one of the keys is chosen
as the primary key; the remaining keys are then referred to as alternate
keys.
A foreign key in one table implies a relation to the primary key in the
other table, and there can be only one primary key.
The normal way to specify the relationship you want is to add a user id
attribute to the UserRole class and use the inverse-foreignkey attribute
in the user roles' collection descriptor.
Over lunch, I had a discussion with a colleague about this. One issue that
came up during the discussion was that if your alternate key can change,
then it should not be used as the foreign key part of a composite primary
key in a related table because primary keys should never change. So, by
virtue that you would have to cascade the alternate key changes to the
primary key of a related table, then the alternate key is no longer
acceptable as a foreign key in the related table.
One other solution that came up was to have the following tables...
User (userId, username, password)
UserRole (userId, rolename)
...and the following view...
UserRoleView (username, rolename)
...based on the User/UserRole relationship. This approach nicely achieves
my goal of preserving normalization (not duplicating both userId and
username in the UserRole table), and still providing the data navigation
required by DataSourceRealm/JDBCRealm to find roles based on
username/password credentials.
So, I get to have my cake (UserRoles collection in the User class based on
userId relationship to UserRole) and eat it too (still compatible with
Tomcat Realms).
Pulat Yunusov [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I don't think what you want is possible because it goes against concepts
of row indentity and referential integrity.
A foreign key in one table implies a relation to the primary key in the
other table, and there can be only one primary key.
The normal way to specify the relationship you want is to add a user id
attribute to the UserRole class and use the inverse-foreignkey attribute
in the user roles' collection descriptor.
Pulat
Sean Dockery wrote:
Hello.
I've searched the gmane archives, but I was unable to find any messages
related to my question.
Suppose that I have the following classes...
public class User {
private Integer id; // primary key field
private String username; // alternate key field
private Collection userRoles; // collection of UserRole objects
related by username
};
public class UserRole {
private String username; // foreign key
private String rolename;
}
...and I wanted to relate User and UserRole in a repository mapping
based on the equality of the username fields in both User and UserRole.
Can this exact schema be handled through a repository mapping? (Does
fk-pointing-to-this-class work without using an indirection-table? Is
there an alternative?)
Most of the rest of the data model in the application uses User.id as a
foreign key, so we can't easily change the primary key of the user
table.
The UserRole fields were chosen for compatibility with Tomcat
JDBCRealm-like declarative security implementations.
The only way that I can see to work around this problem is to duplicate
the User.id field in the UserRole table, along with the username.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: VARCHAR primarykey based upon OJB HighLow sequence in SQL Server 2000
For posterity, overriding the single method worked, but I had to do two
other things:
1) Change the internal OJB descriptors such that the jdbc-type was a BIGINT
instead of an INTEGER.
2) Changed the OJB_HL_SEQ schema such that the max_key column was created
as a bigint instead of an int.
I seeded the OJB_HL_SEQ table with a record having a max_key value of
$F000 (in decimal form) and everything worked as expected. Far easier
than I expected. :-)
Sean Dockery [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hello,
I am working with a content-heavy database application that uses OJB
1.0RC5
on SQL Server 2000. Because the content is part of the value-proposition
for customers to purchase our application, we would like a means of
easily
identifying what (template) data came from us versus what data was
created
by customers during their use of the application.
The hope is that we can have a primarykey of a VARCHAR type that contains
the hexadecimal format of the uniqueID issued by the HighLow sequence
manager implementation. For example, our customer records would begin at
$F000 for records that they create. Everything from $ to
$EFFF would be part of our template data.
I have the source code to the version of OJB that we're using, but I am
unsure where I should make the change? Can I get away with just
sub-classing SequenceManagerHighLowImpl and overriding the getUniqueValue
method?
Here's the implementation that I had been thinking of...
public Object getUniqueValue(FieldDescriptor field) throws
SequenceManagerException {
Object value = super.getUniqueValue(field);
if (VARCHAR.equals(field.getColumnType())) {
value = Long.toString(Long.parseLong(value.toString()), 16);
}
return value;
}
There are tables in the application which use the hi/lo manager for
legitimate integer unique ids; I don't want to interfere with that
operation.
Any comments?
Thanks in advance for your help.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: What should I use for the initial value of a collection field in a new object? and a related question.
Still no recommendations? (I'm posting this through Gmane; can everyone
on the mailing list read this?)
Sean Dockery wrote:
No recommendations?
Sean Dockery wrote:
I have an application that uses the ODMG personality of OJB. I query
objects and collections using PersistenceBroker Criteria; the
PersistenceBroker is obtained from a Transaction object (via
TransactionExt). Objects are stored via a tx.lock plus a tx.markDirty
call. The application uses the default cache implementation.
My question is: What should I use as the initial value of a
collection field in newly created business objects?
Consider the following simple class:
public class Category {
private Collection products;
public Collection getProducts() {
return products;
}
public void setProducts(Collection newProducts) {
products = newProducts;
}
}
When I create the Category object and store it in the cache, the next
fetch retrieves that same Category object reference that was stored.
The products field is null because it was never initialized.
What value should I use when initializing the field? Can I use a
plain old Collection of some sort (LinkedList, ArrayList, HashMap, et
al) or are there some factory methods inside OJB from which I can
obtain an instance of the default collection class.
One other thing: Because collection fields of objects retrieved from
the database are typically of type RemovalAwareCollection, is it safe
to replace the field value with a setProducts(plainOldList) or should
I be modifying the collection via getProducts().add() and
getProducts().remove()? Does it matter?
These two questions seem related (to me) by the fact that if I use a
standard Collection subclass when I create an object and store it in
the cache, it will never see a RemovalAwareCollection (for example)
until the object has been purged from the cache and reloaded.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Behavior of ODMG personality and many-to-many relationships and default cache implementation
Still no takers? :-(
Sean Dockery wrote:
No takers?
Sean Dockery wrote:
Consider the following classes that represent a many-to-many
relationship:
public class Category {
private Collection products;
public Collection getProducts() {
return products;
}
public void setProducts(Collection newProducts) {
products = newProducts;
}
}
public class Products {
private Collection categories;
public Collection getCategories() {
return categories;
}
public void setCategories(Collection newCategories) {
categories = newCategories;
}
}
If I have categories A and B, and products X and Y. Initially
category A contains only product X, and category B contains only
product Y.
If I have fetched category A into the cache, then load product Y, and
modify it thusly...
productY.getCategories().add(categoryA);
...and save it, the correct record is inserted into the indirection
table describing the relationship between categoryA and productY.
However, the cached copy of A is not updated with the new
relationship. If categoryA is purged from the cache and
re-materialized, it contains both X and Y in its products collection.
Is this correct behavior or is this a bug? If it is a bug, will it be
fixed before 1.0 final is released?
Thanks...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Order of elements in the repository_user.xml file
Are the class-descriptor nodes in the repository_user.xml file order dependent? I have a large-ish file that I would like to alphabetize in order to locating relevant class-descriptor nodes, but I'd hate to find out that the dependent nodes had to be declared before nodes that used them (in a reference-descriptor or collection-descriptor, for example). Thanks... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What should I use for the initial value of a collection field in a new object? and a related question.
Armin Waibel wrote:
Hi Sean,
Sean Dockery wrote:
Still no recommendations? (I'm posting this through Gmane; can
everyone on the mailing list read this?)
Sorry for the late reply, but I'm overwhelmed with posts and todo's.
No worries. I was just beginning to wonder if my posts were going
beyond Gmane.
Sean Dockery wrote:
No recommendations?
Sean Dockery wrote:
I have an application that uses the ODMG personality of OJB. I
query objects and collections using PersistenceBroker Criteria; the
PersistenceBroker is obtained from a Transaction object (via
TransactionExt). Objects are stored via a tx.lock plus a
tx.markDirty call. The application uses the default cache
implementation.
My question is: What should I use as the initial value of a
collection field in newly created business objects?
Consider the following simple class:
public class Category {
private Collection products;
public Collection getProducts() {
return products;
}
public void setProducts(Collection newProducts) {
products = newProducts;
}
}
When I create the Category object and store it in the cache, the
next fetch retrieves that same Category object reference that was
stored. The products field is null because it was never initialized.
What do you mean with 'create' - query for an Category or insert a new
Category object?
I'm talking about the case of inserting a new Category object that does
not exist in the database.
Did you set auto-retrieve 'false' in your collection-descriptor for
product? In that case call PB.retrieveAllReferences(...) on the main
object to force loading of references (and cache object again if you
want the full materialized object cached)
I typically have auto-retrieve set to true.
You can use the 'refresh' attribute in the collection-descriptor to
force loading of the collection on each main object request (this work
for cached objects too) - need auto-retrieve 'true'
I have seen the refresh attribute in the DTD, but I have been unsure as
to how it works. I will try this.
What value should I use when initializing the field? Can I use a
plain old Collection of some sort (LinkedList, ArrayList, HashMap,
et al) or are there some factory methods inside OJB from which I can
obtain an instance of the default collection class.
You mean initialization on insert of main object? This will work with
all Collection or ManageableCollection implementations.
This is useful to know. I would prefer to create a Category object and
assign Products to it within a single transaction.
One other thing: Because collection fields of objects retrieved
from the database are typically of type RemovalAwareCollection, is
it safe to replace the field value with a setProducts(plainOldList)
or should I be modifying the collection via getProducts().add() and
getProducts().remove()? Does it matter?
AFAIK RemovalAwareCollection was introduced to allow collection
handling, in particular removal of collection objects on PB-level, in
the same way as on odmg-level. So I would recommend the second
'modifying' way to go.
I will confirm for myself that...
tx.lock(category, Transaction.WRITE);
category.getProducts().add(thisProduct);
category.getProducts().add(thatProduct);
tx.commit();
...work similarly to...
tx.lock(category, Transaction.WRITE);
category.setProducts(theseProducts);
tx.commit();
These two questions seem related (to me) by the fact that if I use a
standard Collection subclass when I create an object and store it in
the cache, it will never see a RemovalAwareCollection (for example)
until the object has been purged from the cache and reloaded.
hmm, valid argument never think about this. In that case you can use
PB.retrieveAllReferences(...)/retrieveReference(...) to re-assign the
collection after insert or remove the object from cache after insert.
So, the following will work...
Category category = new Category();
tx.lock(category, Transaction.WRITE);
Collection products = new LinkedList();
products.add(thisProduct);
products.add(thatProduct);
category.setProducts(products);
tx.commit();
broker.retrieveReference(category, products);
// Confirm that our LinkedList has been replaced
// by a ManageableCollection
if (category.getProducts() instanceof ManageableCollection) {
System.out.println(yes);
}
else {
System.out.println(nope);
}
...when refresh is set to true on the collection descriptor?
regards,
Armin
Thanks for your time, Armin.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: What should I use for the initial value of a collection field in a new object? and a related question.
No recommendations?
Sean Dockery wrote:
I have an application that uses the ODMG personality of OJB. I query
objects and collections using PersistenceBroker Criteria; the
PersistenceBroker is obtained from a Transaction object (via
TransactionExt). Objects are stored via a tx.lock plus a tx.markDirty
call. The application uses the default cache implementation.
My question is: What should I use as the initial value of a collection
field in newly created business objects?
Consider the following simple class:
public class Category {
private Collection products;
public Collection getProducts() {
return products;
}
public void setProducts(Collection newProducts) {
products = newProducts;
}
}
When I create the Category object and store it in the cache, the next
fetch retrieves that same Category object reference that was stored. The
products field is null because it was never initialized.
What value should I use when initializing the field? Can I use a plain
old Collection of some sort (LinkedList, ArrayList, HashMap, et al) or
are there some factory methods inside OJB from which I can obtain an
instance of the default collection class.
One other thing: Because collection fields of objects retrieved from
the database are typically of type RemovalAwareCollection, is it safe to
replace the field value with a setProducts(plainOldList) or should I be
modifying the collection via getProducts().add() and
getProducts().remove()? Does it matter?
These two questions seem related (to me) by the fact that if I use a
standard Collection subclass when I create an object and store it in the
cache, it will never see a RemovalAwareCollection (for example) until
the object has been purged from the cache and reloaded.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Behavior of ODMG personality and many-to-many relationships and default cache implementation
No takers?
Sean Dockery wrote:
Consider the following classes that represent a many-to-many relationship:
public class Category {
private Collection products;
public Collection getProducts() {
return products;
}
public void setProducts(Collection newProducts) {
products = newProducts;
}
}
public class Products {
private Collection categories;
public Collection getCategories() {
return categories;
}
public void setCategories(Collection newCategories) {
categories = newCategories;
}
}
If I have categories A and B, and products X and Y. Initially category
A contains only product X, and category B contains only product Y.
If I have fetched category A into the cache, then load product Y, and
modify it thusly...
productY.getCategories().add(categoryA);
...and save it, the correct record is inserted into the indirection
table describing the relationship between categoryA and productY.
However, the cached copy of A is not updated with the new relationship.
If categoryA is purged from the cache and re-materialized, it contains
both X and Y in its products collection.
Is this correct behavior or is this a bug? If it is a bug, will it be
fixed before 1.0 final is released?
Thanks...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Behavior of ODMG personality and many-to-many relationships and default cache implementation
No takers?
Sean Dockery wrote:
Consider the following classes that represent a many-to-many relationship:
public class Category {
private Collection products;
public Collection getProducts() {
return products;
}
public void setProducts(Collection newProducts) {
products = newProducts;
}
}
public class Products {
private Collection categories;
public Collection getCategories() {
return categories;
}
public void setCategories(Collection newCategories) {
categories = newCategories;
}
}
If I have categories A and B, and products X and Y. Initially category
A contains only product X, and category B contains only product Y.
If I have fetched category A into the cache, then load product Y, and
modify it thusly...
productY.getCategories().add(categoryA);
...and save it, the correct record is inserted into the indirection
table describing the relationship between categoryA and productY.
However, the cached copy of A is not updated with the new relationship.
If categoryA is purged from the cache and re-materialized, it contains
both X and Y in its products collection.
Is this correct behavior or is this a bug? If it is a bug, will it be
fixed before 1.0 final is released?
Thanks...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
What should I use for the initial value of a collection field in a new object? and a related question.
I have an application that uses the ODMG personality of OJB. I query
objects and collections using PersistenceBroker Criteria; the
PersistenceBroker is obtained from a Transaction object (via
TransactionExt). Objects are stored via a tx.lock plus a tx.markDirty
call. The application uses the default cache implementation.
My question is: What should I use as the initial value of a collection
field in newly created business objects?
Consider the following simple class:
public class Category {
private Collection products;
public Collection getProducts() {
return products;
}
public void setProducts(Collection newProducts) {
products = newProducts;
}
}
When I create the Category object and store it in the cache, the next
fetch retrieves that same Category object reference that was stored.
The products field is null because it was never initialized.
What value should I use when initializing the field? Can I use a plain
old Collection of some sort (LinkedList, ArrayList, HashMap, et al) or
are there some factory methods inside OJB from which I can obtain an
instance of the default collection class.
One other thing: Because collection fields of objects retrieved from
the database are typically of type RemovalAwareCollection, is it safe to
replace the field value with a setProducts(plainOldList) or should I be
modifying the collection via getProducts().add() and
getProducts().remove()? Does it matter?
These two questions seem related (to me) by the fact that if I use a
standard Collection subclass when I create an object and store it in the
cache, it will never see a RemovalAwareCollection (for example) until
the object has been purged from the cache and reloaded.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Behavior of ODMG personality and many-to-many relationships and default cache implementation
Consider the following classes that represent a many-to-many relationship:
public class Category {
private Collection products;
public Collection getProducts() {
return products;
}
public void setProducts(Collection newProducts) {
products = newProducts;
}
}
public class Products {
private Collection categories;
public Collection getCategories() {
return categories;
}
public void setCategories(Collection newCategories) {
categories = newCategories;
}
}
If I have categories A and B, and products X and Y. Initially category
A contains only product X, and category B contains only product Y.
If I have fetched category A into the cache, then load product Y, and
modify it thusly...
productY.getCategories().add(categoryA);
...and save it, the correct record is inserted into the indirection
table describing the relationship between categoryA and productY.
However, the cached copy of A is not updated with the new relationship.
If categoryA is purged from the cache and re-materialized, it contains
both X and Y in its products collection.
Is this correct behavior or is this a bug? If it is a bug, will it be
fixed before 1.0 final is released?
Thanks...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Object references... Fetched in a separate thread?
Hello, Rainer. I believe that you misunderstand. The behaviour that I described is exactly the opposite of what you seem to suggest. I don't suffer my productCategory reference becoming null because I sleep for 50 milliseconds. Just the opposite... I have to sleep for 50 milliseconds before my productCategory reference becomes valid. Rainer Klute [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hm, reminds me of the problem I encounter with the cache. Depending on which cache implementation I use my application behaves differently. In your case, could it be the garbage collector removes your ProductCategory instance while your main thread is asleep? Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 On Sat, 21 Feb 2004 00:18:55 -0700 Sean Dockery [EMAIL PROTECTED] wrote: Hello there. I've had a curious experience recently with OJB, and I was wondering if someone could confirm my speculations about the behaviour. Suppose I have two objects... Product and ProductCategory. The Product object carries both a productCategoryId field as well as a reference field productCategory which is declared as auto-retrieve in my class descriptor. Consider the following code segment... Transaction tx = implementation.newTransaction(); tx.begin(); PersistenceBroker broker = ((HasBroker) tx).getBroker(); Product template = new Product(); template.setId(productId); Identity identity = new Identity(template, broker); Product result = (Product) broker.getObjectByIdentity(identity); tx.commit(); // Thread.sleep(50); System.out.println(result.getProductCategory().getName()); Curiously, I sometimes experience a null pointer exception because result.getProductCategory() return null. When I uncomment the Threat.sleep() call, the null pointer exception never happens. This seems to suggest that the productCategory reference is being loaded by another thread. Is this the case or can someone explain why Product.getProductCategory returns null for me sometimes when I first retrieve the Product object? Thanks for your time... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Object references... Fetched in a separate thread?
Armin Waibel [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Sean, Hello, Armin. I'm nearly sure that OJB never starts new threads by its own. AFAIK only the commons-DBCP api starts a new thread (if you enable it) to monitor/manage the used connections (used in a ConnectionFactory implementation, but per default OJB use it's own connection pool). I looked in the OJB.properties file and found the following... ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryP ooledImpl ...and the line with DBCP is commented out, so it doesn't look like DBCP is the culprit. maintaining uses an opaque persistence framework that extends OJB; it Do this framework use unchanged OJB sources? I can't know for sure, but I doubt it. The framework was licensed with the application that was produced by this consulting company (that is, the same company that produced this framework wrote a custom software application based on their framework). Having worked with their source code for the application, I don't think that they would be capable of that. I've been working on this problem off and on for about a week now; if anyone knows of a solution, please post it here. If I find the solution, I'll do the same. Thanks. regards, Armin Sean Dockery wrote: Unfortunately, I'm stuck on version 0.9.8. The application that I'm maintaining uses an opaque persistence framework that extends OJB; it creates classes explicitly which have disappeared between 0.9.8 and 1.0RC4. But because I'm using PB calls directly, I'm certain that this problem has nothing to do with the opaque persistence framework. (The value of this software company's persistence framework is dubious; I'll be glad when we can rid ourselves of it.) Antonio Gallardo [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Sean: AFAIK, this would not happen. BTW, what version are you using? Best Regards, Antonio Gallardo Sean Dockery dijo: Hello there. I've had a curious experience recently with OJB, and I was wondering if someone could confirm my speculations about the behaviour. Suppose I have two objects... Product and ProductCategory. The Product object carries both a productCategoryId field as well as a reference field productCategory which is declared as auto-retrieve in my class descriptor. Consider the following code segment... Transaction tx = implementation.newTransaction(); tx.begin(); PersistenceBroker broker = ((HasBroker) tx).getBroker(); Product template = new Product(); template.setId(productId); Identity identity = new Identity(template, broker); Product result = (Product) broker.getObjectByIdentity(identity); tx.commit(); // Thread.sleep(50); System.out.println(result.getProductCategory().getName()); Curiously, I sometimes experience a null pointer exception because result.getProductCategory() return null. When I uncomment the Threat.sleep() call, the null pointer exception never happens. This seems to suggest that the productCategory reference is being loaded by another thread. Is this the case or can someone explain why Product.getProductCategory returns null for me sometimes when I first retrieve the Product object? Thanks for your time... - 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]
Questions about using Connection objects from a PB, and how long is Iterator from PB.getIterByQuery valid
Two questions...
1) Getting connections from a PersistenceBroker...
In the documentation, it says that you can acquire a connection object
directly from the PB API. By the fact that you can also acquire brokers
from an Implementation instance, can I assume that the following is legal?
Implementation odmg = OJB.getInstance();
Transaction tx = odmg.getTransaction();
tx.beginTransaction();
PersistenceBroker broker = ((HasBroker) tx).getBroker();
Connection connection = broker.serviceConnectionManager().getConnection();
PreparedStatement statement = connection.prepareStatement(sql);
ResultSet resultSet = statement.executeQuery();
//...
tx.commitTransaction();
The docs says to NOT close a connection... but what about Statement and
ResultSet resources?
2) Using PersistenceBroker.getIteratorByQuery...
Is the iterator returned by PersistenceBroker.getIteratorByQuery valid
after the persistence broker has been closed (either explicitly because I'm
using the PB API or implicitly by closing the an ODMG transaction. That
is, is this valid...
Implementation odmg = OJB.getInstance();
Transaction tx = odmg.getTransaction();
tx.beginTransaction();
PersistenceBroker broker = ((HasBroker) tx).getBroker();
Criteria criteria = new Criteria();
criteria.addEqualTo(category.id, category.getId());
criteria.addOrderByAscending(name);
Query query = QueryFactory.newQuery(Product.class, criteria);
Iterator iterator = broker.getIteratoryByQuery(query);
tx.commitTransaction();
while(iterator.hasNext()) {
Product product = (Product) iterator.next();
// blah blah blah
}
Is it valid to use the iterator after the transaction has been committed
(i.e.: broker has been closed)?
Thanks for your time...
--
Sean Dockery
Software Developer
Securac Technologies Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Questions about using Connection objects from a PB, and how long is Iterator from PB.getIterByQuery valid
That's great, Armin. Thanks.
Armin Waibel [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi Sean,
Sean Dockery wrote:
Two questions...
1) Getting connections from a PersistenceBroker...
In the documentation, it says that you can acquire a connection object
directly from the PB API. By the fact that you can also acquire
brokers
from an Implementation instance, can I assume that the following is
legal?
Implementation odmg = OJB.getInstance();
Transaction tx = odmg.getTransaction();
tx.beginTransaction();
PersistenceBroker broker = ((HasBroker) tx).getBroker();
Connection connection =
broker.serviceConnectionManager().getConnection();
PreparedStatement statement = connection.prepareStatement(sql);
ResultSet resultSet = statement.executeQuery();
//...
tx.commitTransaction();
The docs says to NOT close a connection... but what about Statement and
ResultSet resources?
The Statement and ResultSet are straightly opened by yourself, so you
have to close these resources by yourself.
2) Using PersistenceBroker.getIteratorByQuery...
Is the iterator returned by PersistenceBroker.getIteratorByQuery valid
after the persistence broker has been closed (either explicitly because
I'm
using the PB API or implicitly by closing the an ODMG transaction.
That
is, is this valid...
Implementation odmg = OJB.getInstance();
Transaction tx = odmg.getTransaction();
tx.beginTransaction();
PersistenceBroker broker = ((HasBroker) tx).getBroker();
Criteria criteria = new Criteria();
criteria.addEqualTo(category.id, category.getId());
criteria.addOrderByAscending(name);
Query query = QueryFactory.newQuery(Product.class, criteria);
Iterator iterator = broker.getIteratoryByQuery(query);
tx.commitTransaction();
while(iterator.hasNext()) {
Product product = (Product) iterator.next();
// blah blah blah
}
Is it valid to use the iterator after the transaction has been
committed
(i.e.: broker has been closed)?
This will (should ;-)) cause an exception, because the DB resources used
by the iterator will be closed at tx.commit.
So the answer is no.
After the PB instance was closed, the instance itself (the PB handle)
will become invalid, all further method calls should cause an exception
(except PB.close(), PB.isClosed(), PB.isInTransaction())
regards,
Armin
Thanks for your time...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Safe to mix ODMG and PB?
If my application is using the ODMG personality of OJB a la...
Implementation odmg = OBJ.getInstance();
...
Is it safe for other parts of my code to use a PersistenceBroker like
this...
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
try {
// ...
}
finally {
broker.close();
}
...or should I always (on pain of death) get a PersistenceBroker like
this...
Implementation odmg = OJB.getInstance();
Transaction tx = odmg.newTransaction();
tx.begin();
PersistenceBroker broker = ((HasBroker) tx).getBroker();
//...
tx.commit();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Real world OJB applications
Hello, Thomas. Thanks for the link to the references page. I have looked at some of the sample applications, but I'm not sure that sample applications will provide the information that I'm looking for. The problem with sample applications is that you can't be sure whether or not how OJB is used in the sample applications is necessarily of how it lives in the wild. When I am faced with a decision of how to go about something, it is sometime reassuring to find instances in applications in the wild where the same compromises were made or approaches were taken. There is a proverb that says something along the lines of, when all you have in your toolbox is a hammer, the whole world starts to look like a nail. I just want to have as many tools (i.e.: knowledge of approaches to using OJB) as possible. Thomas Mahler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Sean, We have a page listing reference usages and user testimonials: http://db.apache.org/ojb/references.html some of these projects are open source. We also have sample apps in our contributions package. You'll find more details on this page: http://db.apache.org/ojb/links.html#OJB tutorials. cheers, thomas Sean Dockery wrote: Are there any OJB applications available with source on the web? - 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: Real world OJB applications
I mean typical as in a good example of how to use OJB. I'm not concerned with what the user interface medium happens to be; I just want some exposure to approaches taken in the real world applications using OJB that have been proven to be viable. Do you have a sense of which of the ODMG or PB personalities are used more often? I've read (and reread) the pages where it talks about what using ODMG gets you, but it doesn't easily translate into what the correlating pitfall in using PB is. Thomas Mahler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Sean, Sean Dockery wrote: Thanks. I've downloaded it and will look at it later this weekend. Is OpenEMed an example of a typical OJB application? Mhh, What do you mean by typical? OJB is used in large variety of application scenarios. (E.G. in Swing based clients, in Servlets, in EJB Session beans, hooked into a CORBA transaction service, etc.) The only thing that all applications have in common is: they are java apps that need access to a reletional database. In so far OpenEMed is quite typical ;-) cheers, thomas David Forslund [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] http://OpenEMed.org (a sourceforge project) uses OJB as its default persistent store. It doesn't use all the features of OJB but has it integrated as an optional (preferred) persistent store mechanism. At 01:23 PM 1/9/2004, Sean Dockery wrote: Are there any OJB applications available with source on the web? David W. Forslund [EMAIL PROTECTED] Computer and Computational Sciences http://www.acl.lanl.gov/~dwf Los Alamos National Laboratory Los Alamos, NM 87545 505-663-5218FAX: 505-663-5225 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to program against the ODMG personality correctly?
Hello, Philippe.
Thanks for the analysis and tip about the performance of ODMG in relation
to caching objects. That is helpful.
I have a question for you about your little snippet...
PersistenceBroker broker = ((TransactionImpl) tx).getBroker();
A aDummyObject = new A();
aDummyObject.setId(id);
Query qry = new QueryByIdentity(aDummyObject);
A result = (A) broker.getObjectByQuery(qry);
On the OJB web site, it shows the following usage.
PersistenceBroker broker = ((HasBroker) tx).getBroker();
The use of HasBroker seems cleaner than TransactionImpl to me. I know
that since 0.9.8 that classes have disappeared. :-( (I'm working on an
application that uses a closed-source third party library based on OJB
0.9.8; I know that classes have disappeared because I couldn't run the
application with OJB 1.0.)
You could also do this instead...
Identity identity = new Identity(aDummyObject);
A result = (A) broker.getObjectByIdentity(identity);
Is there any difference in behaviour betwen getObjectByQuery and
getObjectByIdentity when it comes to caching? Or is it just a style
(using query vs. identity) preference?
Thanks again, Philippe. I look forward to your reply.
Philippe Hacquin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi Sean,
I'm not an OJB-ODMG expert, but maybe I can help
Sean Dockery wrote:
[...]
1) The exception handling code is omitted from the examples for the
sake
of brevity. Is the manner in which I'm handling exceptions correct?
Take care of the following:
Transaction tx = implementation.newTransaction();
tx.begin();
try
{
tx.commit();
}
catch (Throwable t)
{
tx.abort();
throw new DaoException(t);
}
You may catch a TransactionAbortedException, which in this case will
leave tx null, thus you will end with a NPE if you execute tx.abort()
2) I've written my retrieval routine to use a persistence broker query.
Using persistence broker queries in this manner is apparently faster.
In
a reply in another thread, I read...
Philippe Hacquin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
... and they are much more efficient, too, because they use the cache.
This confuses me somewhat. Does this mean that the ODMG personality of
OJB doesn't use caching? Or do OQL queries bypass caching?
I've recently made some performance tests, with p6spy and network traces
to monitor the queries sent to the database. I am using ODMG in OJB 1.0
RC4, too.
Say you have a class A that has some properties, with at least the id
property which is mapped to the primary key of your table (hence, you
don't use anonymous keys).
You want to get a reference to a persistent object using the id. So you
write an OQL query like select anInstance from + A.class.getname() +
where id = \ + id + \
Well, you have to know this ODMG query will lead to a straight SQL query
to the database, even if the object is already in the cache. But the
cache will anyway be looked up after the SQL query, to check if the
materialization process can be avoided. This process consumes some time,
you can check that during some tests. So an ODMG query uses the cache,
but does not use at 100%.
To use the cache in an effectively manner, you have to use a PB query
against the object Identity (well, this is what I deducted, if there is
a more efficient way to do it with the default cache, I'd like to hear
about it).
This is the way I code it:
PersistenceBroker broker = ((TransactionImpl) tx).getBroker();
A aDummyObject = new A();
aDummyObject.setId(id);
Query qry = new QueryByIdentity(aDummyObject);
A result = (A) broker.getObjectByQuery(qry);
This way the cache is looked up _before_ querying the DB.
This was not obvious when I began using OJB, but should have if I had
carefully read the Object cache documentation: the lookup() method
takes an Identity instance as search key in the cache.
Well, I supposed this was handled transparently in the ODMG
implementation layer...
HTH
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Real world OJB applications
Thanks. I've downloaded it and will look at it later this weekend. Is OpenEMed an example of a typical OJB application? David Forslund [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] http://OpenEMed.org (a sourceforge project) uses OJB as its default persistent store. It doesn't use all the features of OJB but has it integrated as an optional (preferred) persistent store mechanism. At 01:23 PM 1/9/2004, Sean Dockery wrote: Are there any OJB applications available with source on the web? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] David W. Forslund [EMAIL PROTECTED] Computer and Computational Sciences http://www.acl.lanl.gov/~dwf Los Alamos National Laboratory Los Alamos, NM 87545 505-663-5218FAX: 505-663-5225 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to program against the ODMG personality correctly?
I posted this right around new years, but I have not seen any responses
since then and some of these questions are still eating at me. Can anyone
provide any answers to some of the questions that I've asked?
Thanks in advance.
Sean Dockery [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hello there.
I'm fairly new to OJB. I've read several of the tutorials and I'm
working
on creating an application from scratch.
Below are three classes that I wrote. One is my DAO class, the second
class
is an inversion-of-control interface that I'm using to populate the
object
after locking it in the DAO class, and the last class is a Struts action
which using the DAO class and provides an implementation of the
UserConfigurator interface.
I was wondering if anyone could provide some feedback and opinions about
the
code. I'm mainly curious about the following:
1) The exception handling code is omitted from the examples for the sake
of
brevity. Is the manner in which I'm handling exceptions correct?
2) I've written my retrieval routine to use a persistence broker query.
Using persistence broker queries in this manner is apparently faster. In
a
reply in another thread, I read...
Philippe Hacquin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
... and they are much more efficient, too, because they use the cache.
This confuses me somewhat. Does this mean that the ODMG personality of
OJB
doesn't use caching? Or do OQL queries bypass caching?
3) I've chose to perform object deletion using the persistence broker
instead of database.deletePersistent. What is the consequence of using
one
over the other?
4) The PB transaction mechanism uses database locks. The ODMG
personality
uses object locks. Yet, the ODMG personality is less performant than the
PB
personality (according to the performance page on the web site.) Last
time
I checked, memory operations were less expensive than database I/O--so I
would have expected ODMG to out-perform PB. Can anyone explain this
apparent contradiction?
5) I've seen an application that uses OJB that performs updates directly
against the database using JDBC. I suspect that the implication is that
cached objects can become out of sync with data in the database. Does
OJB
have a means by which to detect that a row has been changed by another
user?
6) The auto-retrieve attribute must (apparently) be set to true for ODMG.
This seems a little evil in that I will always be retrieving a graph of
objects instead of the single object in which I'm interested. The
application mentioned in question 5 has severe performance problems
related
to database access; I suspect that the root of the performance problems
are
being caused by having auto-retrieve set to true for several key entities
in
the application. What happens to the behaviour of the ODMG
implementation
if auto-retrieve is set to false? (It suggests that this is a no-no on
the
web site, but doesn't elaborate on what problems will arise.) Should I
be
switching to the PB personality of OJB to avoid problems?
7) Why would I choose to use the ODMG personality over the PB
personality?
I've seen some (rather unhelpful) replies saying it depends on your
needs
and I'm looking for something a little more insightful. What does using
the
ODMG personality get me? (I'm not sure what real Object Transactions
are
supposed to be, but that is one of the reasons cited on the web site.)
Thanks very much for your precious time. It is greatly appreciated.
UserDao.java:
package catalyst.dao;
import org.apache.ojb.broker.PersistenceBroker;
import org.apache.ojb.broker.query.Criteria;
import org.apache.ojb.broker.query.Query;
import org.apache.ojb.broker.query.QueryFactory;
import org.apache.ojb.odmg.HasBroker;
import org.apache.ojb.odmg.OJB;
import org.odmg.Implementation;
import org.odmg.Transaction;
import catalyst.domain.User;
public class UserDao {
private static UserDao instance = new UserDao();
private UserDao() {
}
public static UserDao getInstance() {
return instance;
}
private User findUser(Integer userId) throws DaoException {
Implementation odmg = OJB.getInstance();
Transaction tx = odmg.newTransaction();
tx.begin();
try {
PersistenceBroker broker = ((HasBroker) tx).getBroker();
Criteria criteria = new Criteria();
criteria.addEqualTo(userId, userId);
Query query = QueryFactory.newQuery(User.class, criteria);
User user = (User) broker.getObjectByQuery(query);
tx.commit();
return user;
}
catch (Throwable t) {
tx.abort();
throw new DaoException(t);
}
}
private void storeUser(User user, UserConfigurator configurator) throws
DaoException {
Implementation implementation = OJB.getInstance();
Transaction tx = implementation.newTransaction();
tx.begin();
try {
tx.lock(user, Transaction.WRITE);
configurator.configure(user);
tx.commit();
}
catch (Throwable t) {
tx.abort();
throw new DaoException(t);
}
}
public void
Real world OJB applications
Are there any OJB applications available with source on the web? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to program against the ODMG personality correctly?
Hello there.
I'm fairly new to OJB. I've read several of the tutorials and I'm working
on creating an application from scratch.
Below are three classes that I wrote. One is my DAO class, the second class
is an inversion-of-control interface that I'm using to populate the object
after locking it in the DAO class, and the last class is a Struts action
which using the DAO class and provides an implementation of the
UserConfigurator interface.
I was wondering if anyone could provide some feedback and opinions about the
code. I'm mainly curious about the following:
1) The exception handling code is omitted from the examples for the sake of
brevity. Is the manner in which I'm handling exceptions correct?
2) I've written my retrieval routine to use a persistence broker query.
Using persistence broker queries in this manner is apparently faster. In a
reply in another thread, I read...
Philippe Hacquin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
... and they are much more efficient, too, because they use the cache.
This confuses me somewhat. Does this mean that the ODMG personality of OJB
doesn't use caching? Or do OQL queries bypass caching?
3) I've chose to perform object deletion using the persistence broker
instead of database.deletePersistent. What is the consequence of using one
over the other?
4) The PB transaction mechanism uses database locks. The ODMG personality
uses object locks. Yet, the ODMG personality is less performant than the PB
personality (according to the performance page on the web site.) Last time
I checked, memory operations were less expensive than database I/O--so I
would have expected ODMG to out-perform PB. Can anyone explain this
apparent contradiction?
5) I've seen an application that uses OJB that performs updates directly
against the database using JDBC. I suspect that the implication is that
cached objects can become out of sync with data in the database. Does OJB
have a means by which to detect that a row has been changed by another user?
6) The auto-retrieve attribute must (apparently) be set to true for ODMG.
This seems a little evil in that I will always be retrieving a graph of
objects instead of the single object in which I'm interested. The
application mentioned in question 5 has severe performance problems related
to database access; I suspect that the root of the performance problems are
being caused by having auto-retrieve set to true for several key entities in
the application. What happens to the behaviour of the ODMG implementation
if auto-retrieve is set to false? (It suggests that this is a no-no on the
web site, but doesn't elaborate on what problems will arise.) Should I be
switching to the PB personality of OJB to avoid problems?
7) Why would I choose to use the ODMG personality over the PB personality?
I've seen some (rather unhelpful) replies saying it depends on your needs
and I'm looking for something a little more insightful. What does using the
ODMG personality get me? (I'm not sure what real Object Transactions are
supposed to be, but that is one of the reasons cited on the web site.)
Thanks very much for your precious time. It is greatly appreciated.
UserDao.java:
package catalyst.dao;
import org.apache.ojb.broker.PersistenceBroker;
import org.apache.ojb.broker.query.Criteria;
import org.apache.ojb.broker.query.Query;
import org.apache.ojb.broker.query.QueryFactory;
import org.apache.ojb.odmg.HasBroker;
import org.apache.ojb.odmg.OJB;
import org.odmg.Implementation;
import org.odmg.Transaction;
import catalyst.domain.User;
public class UserDao {
private static UserDao instance = new UserDao();
private UserDao() {
}
public static UserDao getInstance() {
return instance;
}
private User findUser(Integer userId) throws DaoException {
Implementation odmg = OJB.getInstance();
Transaction tx = odmg.newTransaction();
tx.begin();
try {
PersistenceBroker broker = ((HasBroker) tx).getBroker();
Criteria criteria = new Criteria();
criteria.addEqualTo(userId, userId);
Query query = QueryFactory.newQuery(User.class, criteria);
User user = (User) broker.getObjectByQuery(query);
tx.commit();
return user;
}
catch (Throwable t) {
tx.abort();
throw new DaoException(t);
}
}
private void storeUser(User user, UserConfigurator configurator) throws
DaoException {
Implementation implementation = OJB.getInstance();
Transaction tx = implementation.newTransaction();
tx.begin();
try {
tx.lock(user, Transaction.WRITE);
configurator.configure(user);
tx.commit();
}
catch (Throwable t) {
tx.abort();
throw new DaoException(t);
}
}
public void createUser(UserConfigurator configurator) throws DaoException {
storeUser(new User(), configurator);
}
public void updateUser(Integer userId, UserConfigurator configurator) throws
DaoException {
storeUser(findUser(userId), configurator);
}
public void deleteUser(Integer userId) throws DaoException {
Implementation odmg = OJB.getInstance();
Transaction tx = odmg.newTransaction();
tx.begin();
try {
QueryFactory.newQuery(Class, Critiera) vs. QueryByCriteria
The examples on the OJB web site show code that uses the following... Query query = new QueryByCriteria(Product.class, criteria); ...instead of... Query query = QueryFactory.newQuery(Product.class, critiera); Would one ever choose the former style of the latter? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
