Re: Support of database views
Yeah, I'm a bit late here. We do not use cache for objects retrieved from views, so the suggestion was correct. Also be aware that on big views (that join lots of table for instance) retrieving objects could be quite expensive. The thing is that db refreshes view each time you call it, unless you are using materialised views which is not the case in dynamic apps. We had some problems because of that. We had to get rid of views and connect to tables directly. Cheers, Vasily On 9/20/06, Hiller, Frank RD-AS2 <[EMAIL PROTECTED]> wrote: Yes, it works. Thank youFrank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:09 An: OJB Users List Betreff: RE: Support of database views Well, that's my guess... > -Original Message- > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > Sent: 19 September 2006 15:08 > To: OJB Users List > Subject: AW: Support of database views > > Ok, I see. > Setting > class="org.apache.ojb.broker.cache.ObjectCacheEmptyImpl"/> > on the specific table (that actually is a view) resolves the problem? > > Frank > > -Ursprüngliche Nachricht- > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. September 2006 16:04 > An: OJB Users List > Betreff: RE: Support of database views > > Yes, but all (by default) all reads ARE transparently cached (to > improve performance). > > So if you've read C, then you do an update of A or B, then you re-read > C - you will not see the updates but the OLD version of C. > > It's a bit difficult to explain, and I'm obviously not being very > clear. > > > > -Original Message- > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > Sent: 19 September 2006 14:52 > > To: OJB Users List > > Subject: AW: Support of database views > > > > I do not expect to automatically update the object in cache > > representing the view. > > After the update of A or B I explicitely read the view. At > that point > > my expactation was to retrieve the new value. The SQL statement > > returns the correct (new) value, but ojb uses the object from the > > cache with the old value. This confuses me a little. > > > > Best regards, > > Frank > > > > > > -Ursprüngliche Nachricht- > > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 19. September 2006 15:23 > > An: OJB Users List > > Betreff: RE: Support of database views > > > > No, it's not really a bug; > > > > Let's say you have objects A, B and C where C is an objject mapped > > onto a view joining A & B. > > > > OJB Caches objects on their Class + PK; when you update an > object, it > > is ejected from the cache based on it's class and PK. > > > > So, let's say C with a PK of one is references A with a PK of 2 > > > > You read from C -> C[1] is inserted in the cache You read A > > -> A[2] is inserted in the cache You update A -> A[2] is > > dropped from the cache but C[1] is still in the cache. > > > > OJB doesn't (and can't) know about the relationship between A & C > > > > If all updates are done from OJB, and if you can derive the PK of C > > (in the above example) from A, then you could implement > some kind of > > listener that says "whenever A is updated, drop C from the cache" > > > > You might also be able to specify that C should never be cached (by > > specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in > > object-cache element for the class in the repostory.xml) > > > > > > Cheers, > > Charles. > > > > > > > -Original Message- > > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > > Sent: 19 September 2006 14:09 > > > To: OJB Users List > > > Subject: AW: Support of database views > > > > > > Additional information: When I explicitely remove the > > objects from the > > > brokers internal cache (broker.removeFromCache(obj)) it works. > > > Is it a bug? > > > > > > Frank > > > > > > -Ursprüngliche Nachricht- > > > Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > > Gesendet: Dienstag, 19. September 2006 13:56 > > > An: OJB Users List > > > Betreff: AW: Support of database views > > > > > > Hi Vasily, > > > > > > using the view as a table (following your recommendation) shows a > > > strange behaviour. >
RE: Support of database views
It was a good guess then ! Glad I could help, Charles. > -Original Message- > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > Sent: 19 September 2006 15:26 > To: OJB Users List > Subject: AW: Support of database views > > Yes, it works. > Thank youFrank > > -Ursprüngliche Nachricht- > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. September 2006 16:09 > An: OJB Users List > Betreff: RE: Support of database views > > Well, that's my guess... > > > -Original Message- > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > Sent: 19 September 2006 15:08 > > To: OJB Users List > > Subject: AW: Support of database views > > > > Ok, I see. > > Setting > > > class="org.apache.ojb.broker.cache.ObjectCacheEmptyImpl"/> > > on the specific table (that actually is a view) resolves > the problem? > > > > Frank > > > > -Ursprüngliche Nachricht- > > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 19. September 2006 16:04 > > An: OJB Users List > > Betreff: RE: Support of database views > > > > Yes, but all (by default) all reads ARE transparently cached (to > > improve performance). > > > > So if you've read C, then you do an update of A or B, then > you re-read > > C - you will not see the updates but the OLD version of C. > > > > It's a bit difficult to explain, and I'm obviously not being very > > clear. > > > > > > > -Original Message- > > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > > Sent: 19 September 2006 14:52 > > > To: OJB Users List > > > Subject: AW: Support of database views > > > > > > I do not expect to automatically update the object in cache > > > representing the view. > > > After the update of A or B I explicitely read the view. At > > that point > > > my expactation was to retrieve the new value. The SQL statement > > > returns the correct (new) value, but ojb uses the object from the > > > cache with the old value. This confuses me a little. > > > > > > Best regards, > > > Frank > > > > > > > > > -Ursprüngliche Nachricht- > > > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > > > Gesendet: Dienstag, 19. September 2006 15:23 > > > An: OJB Users List > > > Betreff: RE: Support of database views > > > > > > No, it's not really a bug; > > > > > > Let's say you have objects A, B and C where C is an > objject mapped > > > onto a view joining A & B. > > > > > > OJB Caches objects on their Class + PK; when you update an > > object, it > > > is ejected from the cache based on it's class and PK. > > > > > > So, let's say C with a PK of one is references A with a PK of 2 > > > > > > You read from C -> C[1] is inserted in the cache You read A > > > -> A[2] is inserted in the cache You update A -> A[2] is > > > dropped from the cache but C[1] is still in the cache. > > > > > > OJB doesn't (and can't) know about the relationship between A & C > > > > > > If all updates are done from OJB, and if you can derive > the PK of C > > > (in the above example) from A, then you could implement > > some kind of > > > listener that says "whenever A is updated, drop C from the cache" > > > > > > You might also be able to specify that C should never be > cached (by > > > specifying the > org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in > > > object-cache element for the class in the repostory.xml) > > > > > > > > > Cheers, > > > Charles. > > > > > > > > > > -Original Message- > > > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > > > Sent: 19 September 2006 14:09 > > > > To: OJB Users List > > > > Subject: AW: Support of database views > > > > > > > > Additional information: When I explicitely remove the > > > objects from the > > > > brokers internal cache (broker.removeFromCache(obj)) it works. > > > > Is it a bug? > > > > > > > > Frank > > > > > > > > -Ursprüngliche Nachricht----- > > > > Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROT
AW: Support of database views
Yes, it works. Thank youFrank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:09 An: OJB Users List Betreff: RE: Support of database views Well, that's my guess... > -Original Message- > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > Sent: 19 September 2006 15:08 > To: OJB Users List > Subject: AW: Support of database views > > Ok, I see. > Setting > class="org.apache.ojb.broker.cache.ObjectCacheEmptyImpl"/> > on the specific table (that actually is a view) resolves the problem? > > Frank > > -Ursprüngliche Nachricht- > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. September 2006 16:04 > An: OJB Users List > Betreff: RE: Support of database views > > Yes, but all (by default) all reads ARE transparently cached (to > improve performance). > > So if you've read C, then you do an update of A or B, then you re-read > C - you will not see the updates but the OLD version of C. > > It's a bit difficult to explain, and I'm obviously not being very > clear. > > > > -Original Message- > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > Sent: 19 September 2006 14:52 > > To: OJB Users List > > Subject: AW: Support of database views > > > > I do not expect to automatically update the object in cache > > representing the view. > > After the update of A or B I explicitely read the view. At > that point > > my expactation was to retrieve the new value. The SQL statement > > returns the correct (new) value, but ojb uses the object from the > > cache with the old value. This confuses me a little. > > > > Best regards, > > Frank > > > > > > -Ursprüngliche Nachricht- > > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 19. September 2006 15:23 > > An: OJB Users List > > Betreff: RE: Support of database views > > > > No, it's not really a bug; > > > > Let's say you have objects A, B and C where C is an objject mapped > > onto a view joining A & B. > > > > OJB Caches objects on their Class + PK; when you update an > object, it > > is ejected from the cache based on it's class and PK. > > > > So, let's say C with a PK of one is references A with a PK of 2 > > > > You read from C -> C[1] is inserted in the cache You read A > > -> A[2] is inserted in the cache You update A -> A[2] is > > dropped from the cache but C[1] is still in the cache. > > > > OJB doesn't (and can't) know about the relationship between A & C > > > > If all updates are done from OJB, and if you can derive the PK of C > > (in the above example) from A, then you could implement > some kind of > > listener that says "whenever A is updated, drop C from the cache" > > > > You might also be able to specify that C should never be cached (by > > specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in > > object-cache element for the class in the repostory.xml) > > > > > > Cheers, > > Charles. > > > > > > > -Original Message- > > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > > Sent: 19 September 2006 14:09 > > > To: OJB Users List > > > Subject: AW: Support of database views > > > > > > Additional information: When I explicitely remove the > > objects from the > > > brokers internal cache (broker.removeFromCache(obj)) it works. > > > Is it a bug? > > > > > > Frank > > > > > > -Ursprüngliche Nachricht- > > > Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > > Gesendet: Dienstag, 19. September 2006 13:56 > > > An: OJB Users List > > > Betreff: AW: Support of database views > > > > > > Hi Vasily, > > > > > > using the view as a table (following your recommendation) shows a > > > strange behaviour. > > > When a field in a table is updated and the matching object > > returns the > > > correct new value the object related to the view (spanning > > two tables > > > ) still holds the old value for a long time (minutes). > > > > > > Have you (or soneome else) ever had such a problem? > > > Is there something I can configure (in ojb.properties)? > > > > > > I'm using OJB 1.0.3 with PB api. > > > > > > Fr
RE: Support of database views
Well, that's my guess... > -Original Message- > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > Sent: 19 September 2006 15:08 > To: OJB Users List > Subject: AW: Support of database views > > Ok, I see. > Setting > class="org.apache.ojb.broker.cache.ObjectCacheEmptyImpl"/> > on the specific table (that actually is a view) resolves the problem? > > Frank > > -Ursprüngliche Nachricht- > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. September 2006 16:04 > An: OJB Users List > Betreff: RE: Support of database views > > Yes, but all (by default) all reads ARE transparently cached > (to improve performance). > > So if you've read C, then you do an update of A or B, then > you re-read C - you will not see the updates but the OLD version of C. > > It's a bit difficult to explain, and I'm obviously not being > very clear. > > > > -Original Message- > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > Sent: 19 September 2006 14:52 > > To: OJB Users List > > Subject: AW: Support of database views > > > > I do not expect to automatically update the object in cache > > representing the view. > > After the update of A or B I explicitely read the view. At > that point > > my expactation was to retrieve the new value. The SQL statement > > returns the correct (new) value, but ojb uses the object from the > > cache with the old value. This confuses me a little. > > > > Best regards, > > Frank > > > > > > -Ursprüngliche Nachricht- > > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 19. September 2006 15:23 > > An: OJB Users List > > Betreff: RE: Support of database views > > > > No, it's not really a bug; > > > > Let's say you have objects A, B and C where C is an objject mapped > > onto a view joining A & B. > > > > OJB Caches objects on their Class + PK; when you update an > object, it > > is ejected from the cache based on it's class and PK. > > > > So, let's say C with a PK of one is references A with a PK of 2 > > > > You read from C -> C[1] is inserted in the cache You read A > > -> A[2] is inserted in the cache You update A -> A[2] is > > dropped from the cache but C[1] is still in the cache. > > > > OJB doesn't (and can't) know about the relationship between A & C > > > > If all updates are done from OJB, and if you can derive the PK of C > > (in the above example) from A, then you could implement > some kind of > > listener that says "whenever A is updated, drop C from the cache" > > > > You might also be able to specify that C should never be cached (by > > specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in > > object-cache element for the class in the repostory.xml) > > > > > > Cheers, > > Charles. > > > > > > > -Original Message- > > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > > Sent: 19 September 2006 14:09 > > > To: OJB Users List > > > Subject: AW: Support of database views > > > > > > Additional information: When I explicitely remove the > > objects from the > > > brokers internal cache (broker.removeFromCache(obj)) it works. > > > Is it a bug? > > > > > > Frank > > > > > > -Ursprüngliche Nachricht- > > > Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > > Gesendet: Dienstag, 19. September 2006 13:56 > > > An: OJB Users List > > > Betreff: AW: Support of database views > > > > > > Hi Vasily, > > > > > > using the view as a table (following your recommendation) shows a > > > strange behaviour. > > > When a field in a table is updated and the matching object > > returns the > > > correct new value the object related to the view (spanning > > two tables > > > ) still holds the old value for a long time (minutes). > > > > > > Have you (or soneome else) ever had such a problem? > > > Is there something I can configure (in ojb.properties)? > > > > > > I'm using OJB 1.0.3 with PB api. > > > > > > Frank > > > > > > -Ursprüngliche Nachricht- > > > Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] > > > Gesendet: Dienstag, 12. September 2006 01:19 > > > An: OJB Users List &
AW: Support of database views
Ok, I see. Setting on the specific table (that actually is a view) resolves the problem? Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 16:04 An: OJB Users List Betreff: RE: Support of database views Yes, but all (by default) all reads ARE transparently cached (to improve performance). So if you've read C, then you do an update of A or B, then you re-read C - you will not see the updates but the OLD version of C. It's a bit difficult to explain, and I'm obviously not being very clear. > -Original Message- > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > Sent: 19 September 2006 14:52 > To: OJB Users List > Subject: AW: Support of database views > > I do not expect to automatically update the object in cache > representing the view. > After the update of A or B I explicitely read the view. At that point > my expactation was to retrieve the new value. The SQL statement > returns the correct (new) value, but ojb uses the object from the > cache with the old value. This confuses me a little. > > Best regards, > Frank > > > -Ursprüngliche Nachricht- > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. September 2006 15:23 > An: OJB Users List > Betreff: RE: Support of database views > > No, it's not really a bug; > > Let's say you have objects A, B and C where C is an objject mapped > onto a view joining A & B. > > OJB Caches objects on their Class + PK; when you update an object, it > is ejected from the cache based on it's class and PK. > > So, let's say C with a PK of one is references A with a PK of 2 > > You read from C -> C[1] is inserted in the cache You read A > -> A[2] is inserted in the cache You update A -> A[2] is > dropped from the cache but C[1] is still in the cache. > > OJB doesn't (and can't) know about the relationship between A & C > > If all updates are done from OJB, and if you can derive the PK of C > (in the above example) from A, then you could implement some kind of > listener that says "whenever A is updated, drop C from the cache" > > You might also be able to specify that C should never be cached (by > specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in > object-cache element for the class in the repostory.xml) > > > Cheers, > Charles. > > > > -Original Message- > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > Sent: 19 September 2006 14:09 > > To: OJB Users List > > Subject: AW: Support of database views > > > > Additional information: When I explicitely remove the > objects from the > > brokers internal cache (broker.removeFromCache(obj)) it works. > > Is it a bug? > > > > Frank > > > > -Ursprüngliche Nachricht- > > Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 19. September 2006 13:56 > > An: OJB Users List > > Betreff: AW: Support of database views > > > > Hi Vasily, > > > > using the view as a table (following your recommendation) shows a > > strange behaviour. > > When a field in a table is updated and the matching object > returns the > > correct new value the object related to the view (spanning > two tables > > ) still holds the old value for a long time (minutes). > > > > Have you (or soneome else) ever had such a problem? > > Is there something I can configure (in ojb.properties)? > > > > I'm using OJB 1.0.3 with PB api. > > > > Frank > > > > -Ursprüngliche Nachricht- > > Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 12. September 2006 01:19 > > An: OJB Users List > > Betreff: Re: Support of database views > > > > Hi Frank, > > > > We used to work with views without any issue, just put > view's name as > > "table" attribute in "class-descriptor". However, you will only be > > able to read objects from that view. > > > > Regards, > > Vasily > > > > On 9/11/06, Hiller, Frank RD-AS2 > <[EMAIL PROTECTED]> wrote: > > > Short question: I couldn't find a functionality to deal > > with database > > > views (create view...) within OJB. > > > Is there a reason for that? > > > Is the answer "use ReportQuery". > > > > > > Thank you, > > > Frank > > > > > > > > > >
RE: Support of database views
Yes, but all (by default) all reads ARE transparently cached (to improve performance). So if you've read C, then you do an update of A or B, then you re-read C - you will not see the updates but the OLD version of C. It's a bit difficult to explain, and I'm obviously not being very clear. > -Original Message- > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > Sent: 19 September 2006 14:52 > To: OJB Users List > Subject: AW: Support of database views > > I do not expect to automatically update the object in cache > representing the view. > After the update of A or B I explicitely read the view. At > that point my expactation was to retrieve the new value. The > SQL statement returns the correct (new) value, but ojb uses > the object from the cache with the old value. This confuses > me a little. > > Best regards, > Frank > > > -Ursprüngliche Nachricht- > Von: Charles Anthony [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. September 2006 15:23 > An: OJB Users List > Betreff: RE: Support of database views > > No, it's not really a bug; > > Let's say you have objects A, B and C where C is an objject > mapped onto a view joining A & B. > > OJB Caches objects on their Class + PK; when you update an > object, it is ejected from the cache based on it's class and PK. > > So, let's say C with a PK of one is references A with a PK of 2 > > You read from C -> C[1] is inserted in the cache You read A > -> A[2] is inserted in the cache You update A -> A[2] is > dropped from the cache but C[1] is still in the cache. > > OJB doesn't (and can't) know about the relationship between A & C > > If all updates are done from OJB, and if you can derive the > PK of C (in the above example) from A, then you could > implement some kind of listener that says "whenever A is > updated, drop C from the cache" > > You might also be able to specify that C should never be > cached (by specifying the > org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in > object-cache element for the class in the repostory.xml) > > > Cheers, > Charles. > > > > -Original Message- > > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > Sent: 19 September 2006 14:09 > > To: OJB Users List > > Subject: AW: Support of database views > > > > Additional information: When I explicitely remove the > objects from the > > brokers internal cache (broker.removeFromCache(obj)) it works. > > Is it a bug? > > > > Frank > > > > -Ursprüngliche Nachricht- > > Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 19. September 2006 13:56 > > An: OJB Users List > > Betreff: AW: Support of database views > > > > Hi Vasily, > > > > using the view as a table (following your recommendation) shows a > > strange behaviour. > > When a field in a table is updated and the matching object > returns the > > correct new value the object related to the view (spanning > two tables > > ) still holds the old value for a long time (minutes). > > > > Have you (or soneome else) ever had such a problem? > > Is there something I can configure (in ojb.properties)? > > > > I'm using OJB 1.0.3 with PB api. > > > > Frank > > > > -Ursprüngliche Nachricht- > > Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 12. September 2006 01:19 > > An: OJB Users List > > Betreff: Re: Support of database views > > > > Hi Frank, > > > > We used to work with views without any issue, just put > view's name as > > "table" attribute in "class-descriptor". However, you will only be > > able to read objects from that view. > > > > Regards, > > Vasily > > > > On 9/11/06, Hiller, Frank RD-AS2 > <[EMAIL PROTECTED]> wrote: > > > Short question: I couldn't find a functionality to deal > > with database > > > views (create view...) within OJB. > > > Is there a reason for that? > > > Is the answer "use ReportQuery". > > > > > > Thank you, > > > Frank > > > > > > > > > > > > Confidentiality note: > > > The information in this email and any attachment may > > contain confidential and proprietary information of Heidelberger > > Druckmaschinen AG and/or its affiliates and may be privileged or > > otherwise protected from disclosure. If you are not
AW: Support of database views
I do not expect to automatically update the object in cache representing the view. After the update of A or B I explicitely read the view. At that point my expactation was to retrieve the new value. The SQL statement returns the correct (new) value, but ojb uses the object from the cache with the old value. This confuses me a little. Best regards, Frank -Ursprüngliche Nachricht- Von: Charles Anthony [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 15:23 An: OJB Users List Betreff: RE: Support of database views No, it's not really a bug; Let's say you have objects A, B and C where C is an objject mapped onto a view joining A & B. OJB Caches objects on their Class + PK; when you update an object, it is ejected from the cache based on it's class and PK. So, let's say C with a PK of one is references A with a PK of 2 You read from C -> C[1] is inserted in the cache You read A -> A[2] is inserted in the cache You update A -> A[2] is dropped from the cache but C[1] is still in the cache. OJB doesn't (and can't) know about the relationship between A & C If all updates are done from OJB, and if you can derive the PK of C (in the above example) from A, then you could implement some kind of listener that says "whenever A is updated, drop C from the cache" You might also be able to specify that C should never be cached (by specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in object-cache element for the class in the repostory.xml) Cheers, Charles. > -Original Message- > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > Sent: 19 September 2006 14:09 > To: OJB Users List > Subject: AW: Support of database views > > Additional information: When I explicitely remove the objects from the > brokers internal cache (broker.removeFromCache(obj)) it works. > Is it a bug? > > Frank > > -Ursprüngliche Nachricht- > Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. September 2006 13:56 > An: OJB Users List > Betreff: AW: Support of database views > > Hi Vasily, > > using the view as a table (following your recommendation) shows a > strange behaviour. > When a field in a table is updated and the matching object returns the > correct new value the object related to the view (spanning two tables > ) still holds the old value for a long time (minutes). > > Have you (or soneome else) ever had such a problem? > Is there something I can configure (in ojb.properties)? > > I'm using OJB 1.0.3 with PB api. > > Frank > > -Ursprüngliche Nachricht- > Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 12. September 2006 01:19 > An: OJB Users List > Betreff: Re: Support of database views > > Hi Frank, > > We used to work with views without any issue, just put view's name as > "table" attribute in "class-descriptor". However, you will only be > able to read objects from that view. > > Regards, > Vasily > > On 9/11/06, Hiller, Frank RD-AS2 <[EMAIL PROTECTED]> wrote: > > Short question: I couldn't find a functionality to deal > with database > > views (create view...) within OJB. > > Is there a reason for that? > > Is the answer "use ReportQuery". > > > > Thank you, > > Frank > > > > > > > > Confidentiality note: > > The information in this email and any attachment may > contain confidential and proprietary information of Heidelberger > Druckmaschinen AG and/or its affiliates and may be privileged or > otherwise protected from disclosure. If you are not the intended > recipient, you are hereby notified that any review, reliance or > distribution by others or forwarding without express permission is > strictly prohibited and may cause liability. In case you have received > this message due to an error in transmission, we kindly ask you to > notify the sender immediately and to delete this email and any > attachment from your system. > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Confidentiality note: > The information in this email and any attachment may contain > confidential and proprietary information of Heidelberger > Druckmaschinen AG and/or its affiliates and may be privileged or > otherwise protected from disclosure. If you are not the intended > recipient, you are hereby notified that any review, reliance or > distribution by others or forwarding without express permission is > strictly prohibited and may cause l
RE: Support of database views
No, it's not really a bug; Let's say you have objects A, B and C where C is an objject mapped onto a view joining A & B. OJB Caches objects on their Class + PK; when you update an object, it is ejected from the cache based on it's class and PK. So, let's say C with a PK of one is references A with a PK of 2 You read from C -> C[1] is inserted in the cache You read A -> A[2] is inserted in the cache You update A -> A[2] is dropped from the cache but C[1] is still in the cache. OJB doesn't (and can't) know about the relationship between A & C If all updates are done from OJB, and if you can derive the PK of C (in the above example) from A, then you could implement some kind of listener that says "whenever A is updated, drop C from the cache" You might also be able to specify that C should never be cached (by specifying the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl in object-cache element for the class in the repostory.xml) Cheers, Charles. > -Original Message- > From: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > Sent: 19 September 2006 14:09 > To: OJB Users List > Subject: AW: Support of database views > > Additional information: When I explicitely remove the objects > from the brokers internal cache (broker.removeFromCache(obj)) > it works. > Is it a bug? > > Frank > > -Ursprüngliche Nachricht- > Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 19. September 2006 13:56 > An: OJB Users List > Betreff: AW: Support of database views > > Hi Vasily, > > using the view as a table (following your recommendation) > shows a strange behaviour. > When a field in a table is updated and the matching object > returns the correct new value the object related to the view > (spanning two tables ) still holds the old value for a long > time (minutes). > > Have you (or soneome else) ever had such a problem? > Is there something I can configure (in ojb.properties)? > > I'm using OJB 1.0.3 with PB api. > > Frank > > -Ursprüngliche Nachricht- > Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 12. September 2006 01:19 > An: OJB Users List > Betreff: Re: Support of database views > > Hi Frank, > > We used to work with views without any issue, just put view's > name as "table" attribute in "class-descriptor". However, you > will only be able to read objects from that view. > > Regards, > Vasily > > On 9/11/06, Hiller, Frank RD-AS2 <[EMAIL PROTECTED]> wrote: > > Short question: I couldn't find a functionality to deal > with database > > views (create view...) within OJB. > > Is there a reason for that? > > Is the answer "use ReportQuery". > > > > Thank you, > > Frank > > > > > > > > Confidentiality note: > > The information in this email and any attachment may > contain confidential and proprietary information of > Heidelberger Druckmaschinen AG and/or its affiliates and may > be privileged or otherwise protected from disclosure. If you > are not the intended recipient, you are hereby notified that > any review, reliance or distribution by others or forwarding > without express permission is strictly prohibited and may > cause liability. In case you have received this message due > to an error in transmission, we kindly ask you to notify the > sender immediately and to delete this email and any > attachment from your system. > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Confidentiality note: > The information in this email and any attachment may contain > confidential and proprietary information of Heidelberger > Druckmaschinen AG and/or its affiliates and may be privileged > or otherwise protected from disclosure. If you are not the > intended recipient, you are hereby notified that any review, > reliance or distribution by others or forwarding without > express permission is strictly prohibited and may cause > liability. In case you have received this message due to an > error in transmission, we kindly ask you to notify the sender > immediately and to delete this email and any attachment from > your system. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Confidentiality note: > The information in this email and any attachment may contain > confidentia
AW: Support of database views
Additional information: When I explicitely remove the objects from the brokers internal cache (broker.removeFromCache(obj)) it works. Is it a bug? Frank -Ursprüngliche Nachricht- Von: Hiller, Frank RD-AS2 [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. September 2006 13:56 An: OJB Users List Betreff: AW: Support of database views Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as "table" attribute in "class-descriptor". However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 <[EMAIL PROTECTED]> wrote: > Short question: I couldn't find a functionality to deal with database > views (create view...) within OJB. > Is there a reason for that? > Is the answer "use ReportQuery". > > Thank you, > Frank > > > > Confidentiality note: > The information in this email and any attachment may contain confidential and > proprietary information of Heidelberger Druckmaschinen AG and/or its > affiliates and may be privileged or otherwise protected from disclosure. If > you are not the intended recipient, you are hereby notified that any review, > reliance or distribution by others or forwarding without express permission > is strictly prohibited and may cause liability. In case you have received > this message due to an error in transmission, we kindly ask you to notify the > sender immediately and to delete this email and any attachment from your > system. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Support of database views
Hi Vasily, using the view as a table (following your recommendation) shows a strange behaviour. When a field in a table is updated and the matching object returns the correct new value the object related to the view (spanning two tables ) still holds the old value for a long time (minutes). Have you (or soneome else) ever had such a problem? Is there something I can configure (in ojb.properties)? I'm using OJB 1.0.3 with PB api. Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as "table" attribute in "class-descriptor". However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 <[EMAIL PROTECTED]> wrote: > Short question: I couldn't find a functionality to deal with database > views (create view...) within OJB. > Is there a reason for that? > Is the answer "use ReportQuery". > > Thank you, > Frank > > > > Confidentiality note: > The information in this email and any attachment may contain confidential and > proprietary information of Heidelberger Druckmaschinen AG and/or its > affiliates and may be privileged or otherwise protected from disclosure. If > you are not the intended recipient, you are hereby notified that any review, > reliance or distribution by others or forwarding without express permission > is strictly prohibited and may cause liability. In case you have received > this message due to an error in transmission, we kindly ask you to notify the > sender immediately and to delete this email and any attachment from your > system. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Support of database views
Good idea, works fine. Thank you..Frank -Ursprüngliche Nachricht- Von: Vasily Ivanov [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 12. September 2006 01:19 An: OJB Users List Betreff: Re: Support of database views Hi Frank, We used to work with views without any issue, just put view's name as "table" attribute in "class-descriptor". However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 <[EMAIL PROTECTED]> wrote: > Short question: I couldn't find a functionality to deal with database > views (create view...) within OJB. > Is there a reason for that? > Is the answer "use ReportQuery". > > Thank you, > Frank > > > > Confidentiality note: > The information in this email and any attachment may contain confidential and > proprietary information of Heidelberger Druckmaschinen AG and/or its > affiliates and may be privileged or otherwise protected from disclosure. If > you are not the intended recipient, you are hereby notified that any review, > reliance or distribution by others or forwarding without express permission > is strictly prohibited and may cause liability. In case you have received > this message due to an error in transmission, we kindly ask you to notify the > sender immediately and to delete this email and any attachment from your > system. > > - 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: Support of database views
Hi Frank, We used to work with views without any issue, just put view's name as "table" attribute in "class-descriptor". However, you will only be able to read objects from that view. Regards, Vasily On 9/11/06, Hiller, Frank RD-AS2 <[EMAIL PROTECTED]> wrote: Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for that? Is the answer "use ReportQuery". Thank you, Frank Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Support of database views
Short question: I couldn't find a functionality to deal with database views (create view...) within OJB. Is there a reason for that? Is the answer "use ReportQuery". Thank you, Frank Confidentiality note: The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system.
Re: Database views
Hi Manjula, OJB requires to have at least one attribute per class defined as primary key. But it is sufficient to delare is as primary key in the field-descriptor. It is not required to be defined a primary key in the database. So for a view you just have to define those attributes as primary that uniquely identify one row in the view. cheers, Thomas Manjula Venugopal (FS) wrote: Hi Thomas, Read your messages about accessing database views using OJB. I have defined a view in Oracle database. And generated Java class using "reverse-db" tool. When i use Persistence broker api class to query, the server throws error org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException: OJB needs at least one primary key attribute for class objectClass=class entity.VBillContract, objectsRealClass=class entity.VBillContract View has no primary key, so do you have any suggestion to over come this problem. I have set "access=readonly" in field descriptors. Thanks, Manjula. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Database views
Hi Peter, Peter Costa wrote: I was wondering if it is possible to map a class in the repository_user.xml to a database view. sure! If it is possible do I just put the view name in the table column on the class descriptor? yes, that's all. To tell OJB that the view columns can not be updated, set access="readonly" in the field-descriptors. cheers, Thomas If you have any other thoughts on how to implement database views, that would be appreciated also. Thank you. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Database views
Hello Peter I am using database views in my project without any problem. you have to map your object to your databaseview like you do it with any table -Mensaje original- De: Peter Costa [mailto:[EMAIL PROTECTED] Enviado el: Wednesday, July 23, 2003 7:16 PM Para: [EMAIL PROTECTED] Asunto: Database views I was wondering if it is possible to map a class in the repository_user.xml to a database view. If it is possible do I just put the view name in the table column on the class descriptor? If you have any other thoughts on how to implement database views, that would be appreciated also. Thank you. Peter Este mensaje puede contener información confidencial y/o privilegiada. Si Vd. no es el destinatario/receptor indicado en este mensaje (o el responsable de entregar el mensaje al destinatario/receptor), no debe copiar o entregar este mensaje a nadie. En ese caso, Vd. debe destruir este mensaje y rápidamente notificárselo al emisor mediante de un correo electrónico. Por favor, avise inmediatamente si Vd. o su empresa no consienten correo electrónico con mensajes de este tipo. Las opiniones, conclusiones o cualquier otra información incluidas en este mensaje y que no haga referencia al negocio y la actividad de Indra Sistemas, S.A.. se entenderá que ni han sido dados, ni aprobados o respaldados por la misma.
Database views
I was wondering if it is possible to map a class in the repository_user.xml to a database view. If it is possible do I just put the view name in the table column on the class descriptor? If you have any other thoughts on how to implement database views, that would be appreciated also. Thank you. Peter
Re: Database views
Hi Raymond, Raymond Barlow wrote: Hi all, I'd like to get a general opinion on what is the best practise for using database views or not. I'm currently converting a system that has a number of views. Some of the views use other views to build up reporting type information. I would think that in a totally clean class driven environment views would be bad, as the tables should only be used for persistence. If views are bad, how do you build up the same sort of thing using OJB/persistant classes? ie. where there were views using views, what is the equivalent way of thinking in OJB? What would you generally do here? If you do not want to use database views you can use OJB report queries to perform arbitrary queries and present the result as a view. But why not use database views and map them to view-classes. I think this can be a good solution in certain cases. just my 2c, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Database views
Hi all, I'd like to get a general opinion on what is the best practise for using database views or not. I'm currently converting a system that has a number of views. Some of the views use other views to build up reporting type information. I would think that in a totally clean class driven environment views would be bad, as the tables should only be used for persistence. If views are bad, how do you build up the same sort of thing using OJB/persistant classes? ie. where there were views using views, what is the equivalent way of thinking in OJB? What would you generally do here? -- Regards, Raymond Barlow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
