We are considering using Beankeeper in a project that will soon go commercial. Since this application will be deployed to client machines via JavaFX (either as an applet or installed application), it will need to have a small database footprint. So, we would LOVE to be able to control historical object retention.
We chose Beankeeper because of its size, lack of configuration requirements, and ease of use. We've already had to work around some of its shortcomings (a la commons-config footprint, as well as support for the H2 embedded database), but this particular issue is a massive showstopper -- we can't have users' disks getting full of old records because of a historical track that they will never use.
If there's anything we can do to help, even so far as offering a patch, please do let me know. Otherwise, I fear I'll have to go looking for another library, which does not excite me in the least.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are considering using Beankeeper in a project that will soon go commercial. Since this application will be deployed to client machines via JavaFX (either as an applet or installed application), it will need to have a small database footprint. So, we would LOVE to be able to control historical object retention.
We chose Beankeeper because of its size, lack of configuration requirements, and ease of use. We've already had to work around some of its shortcomings (a la commons-config footprint, as well as support for the H2 embedded database), but this particular issue is a massive showstopper -- we can't have users' disks getting full of old records because of a historical track that they will never use.
If there's anything we can do to help, even so far as offering a patch, please do let me know. Otherwise, I fear I'll have to go looking for another library, which does not excite me in the least.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are considering using Beankeeper in a project that will soon go commercial. Since this application will be deployed to client machines via JavaFX (either as an applet or installed application), it will need to have a small database footprint. So, we would LOVE to be able to control historical object retention.
We chose Beankeeper because of its size, lack of configuration requirements, and ease of use. We've already had to work around some of its shortcomings (a la commons-config footprint, as well as support for the H2 embedded database), but this particular issue is a massive showstopper -- we can't have users' disks getting full of old records because of a historical track that they will never use.
If there's anything we can do to help, even so far as offering a patch, please do let me know. Otherwise, I fear I'll have to go looking for another library, which does not excite me in the least.
We are considering using Beankeeper in a project that will soon go commercial. Since this application will be deployed to client machines via JavaFX (either as an applet or installed application), it will need to have a small database footprint. So, we would LOVE to be able to control historical object retention.
We chose Beankeeper because of its size, lack of configuration requirements, and ease of use. We've already had to work around some of its shortcomings (a la commons-config footprint, as well as support for the H2 embedded database), but this particular issue is a massive showstopper -- we can't have users' disks getting full of old records because of a historical track that they will never use.
If there's anything we can do to help, even so far as offering a patch, please do let me know. Otherwise, I fear I'll have to go looking for another library, which does not excite me in the least.
Sorry about the repost. Sourceforge doesn't redirect-on-post (stupid webapp).