Discussions

News: pBeans 2.0 released, using annotations instead of class info

  1. pBeans 2.0, an object/relational mapping library, has been released. The major change from previous versions centers around the use of annotations rather than a JavaBean-like class info object. Another interesting feature is the claim for instance consistency - which means an object isn't fetched from DB if it's already cached. pBeans isn't a JPA-compatible persistence library, although it shares many of the characteristics of JPA implementations. It's been without a major update for quite some time, but hasn't "died," so to speak. It's always good to see libraries resume activity. What do you think of the library? Is JPA compatibility a driver for you? What about the requirement for Java 5's annotations capability - is that a limiting factor for you?

    Threaded Messages (13)

  2. Reasons why ?[ Go to top ]

    What do you think of the library? Is JPA compatibility a driver for you? What about the requirement for Java 5's annotations capability - is that a limiting factor for you?
    What is there to think? How is it better than standards-driven O/R mapping tools ? Why should it be considered ? Restricting people to Java5+ is the same as JPA. The more common-sense approach is to use annotations for things that wont change much, and MetaData for things that are specific to an RDBMS's own dialect (that needs changing at deployment). JDO and JPA exist now and have plenty of people who know them. This doesnt. Give reasons please
    Another interesting feature is the claim for instance consistency
    Why is this interesting ? Specifications for ORM have caches L1 and L2.
  3. Agreed[ Go to top ]

    Why is this even interesting? There are plenty of JPA-complient libraries out there, why even bother with one that isn't? Get with the standard.
  4. would like to try[ Go to top ]

    Right now i have to deal with jdbc and boiler-plate insert-update statements are very painful. i need a light weight mechanism to eliminate that. *if* this library does what it says well, i would be gladly using it. Thank god, i am not stucked to some archaic app server so i can use JDK 5 and Annotations are welcome (i think Java 5 is out for 2,5 years already) Hibernate would fix the problem as well, but Not all problems are suitable for ORM or JPA as everybody knows. i dont want to use Hibernate for this because unfortunately it is one big lard ass framework and it's JPA comaptibility seems like forcedly plugged afterwards. if you use it as a JPA implementation you will posibly have like 4-5Megs of jar files scattered into 10-15 files (some of which has nothing to do with JPA). Even if it is not a full ORM solution, give me a 94kb (pbeans) jar any day if it will fix my problem today. if only some brave people make a pure light weight JPA implementation so we would be out of this Grief..
  5. unsuitability of JPA?[ Go to top ]

    Not all problems are suitable for ORM or JPA
    As a member of the EJB3 expert group team, I'd be interested in knowing what pBeans does that makes its interfaces more suitable than the JPA interfaces. We spent a lot of time on the expert group trying to ensure that the barrier to entry into the JPA space wasn't too high. If we somehow screwed that up or in some way created interfaces that don't work for some implementations, it'd be great to know so that we could address this in the next spec version. -Patrick -- Patrick Linskey http://bea.com
  6. Re: unsuitability of JPA?[ Go to top ]

    Oh, and just to clarify, yes, I know that ORM and JPA are not always the right solution for a given problem. -Patrick -- Patrick Linskey http://bea.com
  7. problem is not the JPA[ Go to top ]

    Hi , problem is not JPA. i wish to use JPA really, it is great. But there are two things , First we do not have much control over this project (we entered very late), and the whole thing is designed using crusty JDBC - very database centric and it uses a lot of DB vendor specific stuff. So, introducing JPA itself is hard business-political wise. that is why i just needed something easing the boilerplate coding in JDBC. i am not sure if this framework (pBeans) will provide that. i have my serious doubts now if it is even worthy of trying since they have virtually no documentation. Second thing is the the current JPA implementations. Since JPA is new, there is no framework exclusively designed for JPA. Hibernate and Toplink still carries their heavy legacy code - dependencies within (especially Hibernate). Their source is also not Java 5 (except JPA related areas AFAIK). That is why i would love to see a light weight JPA implementation not having no or very few dependencies. if some people wants to plug a cache, or a criteria query, xml persistence stuff, fine, but leave it out of the core.. ok, i am picky about this issue, but i am tired of copying damned hibernate dependencies.
  8. Re: problem is not the JPA[ Go to top ]

    Did you read the lib/version.properties or lib/readme.txt that shows what dependencies you actually need ? caching libs is not needed unless you actually use it etc.
  9. Re: problem is not the JPA[ Go to top ]

    Second thing is the the current JPA implementations. Since JPA is new, there is no framework exclusively designed for JPA. Hibernate and Toplink still carries their heavy legacy code - dependencies within (especially Hibernate). Their source is also not Java 5 (except JPA related areas AFAIK). That is why i would love to see a light weight JPA implementation not having no or very few dependencies. if some people wants to plug a cache, or a criteria query, xml persistence stuff, fine, but leave it out of the core.. ok, i am picky about this issue, but i am tired of copying damned hibernate dependencies.
    Huh? Have you looked at TopLink Essentials? It has no external dependencies at all, but is a lightweight JPA impl in a single jarfile.
  10. Re: would like to try[ Go to top ]

    Right now i have to deal with jdbc and boiler-plate insert-update statements are very painful. i need a light weight mechanism to eliminate that. *if* this library does what it says well, i would be gladly using it. Thank god, i am not stucked to some archaic app server so i can use JDK 5 and Annotations are welcome (i think Java 5 is out for 2,5 years already)
    Hibernate would fix the problem as well, but Not all problems are suitable for ORM or JPA as everybody knows. i dont want to use Hibernate for this because unfortunately it is one big lard ass framework and it's JPA comaptibility seems like forcedly plugged afterwards. if you use it as a JPA implementation you will posibly have like 4-5Megs of jar files scattered into 10-15 files (some of which has nothing to do with JPA). Even if it is not a full ORM solution, give me a 94kb (pbeans) jar any day if it will fix my problem today. if only some brave people make a pure light weight JPA implementation so we would be out of this Grief..
    The JPA ri is pretty lightweigt two jars no side depenencies, except for the JDK itself, done. The entire we link into 15.000 dependend jars issue was reason enough for me to leave out hibernate for my last project. This has been an issue for years, and often enough also was quoted in here, the JBoss people really have to work on this, a refactoring of the dependencies into a jboss namespace would be enough to resolve this issue! (Maybe it is done already, I havent had a look at Hibernate recently) Seam has the same problem to a bigger extent!
  11. as i can understand ,those features r not supported,am i wrong?
  12. pBeans - Simple As A Walk In The Park... I decided to give pBeans a try and I'm loving it... It's simplicity makes it very easy to use. Here are some things I observed using this tool... 1. Since there are no relationships it's upto you to delete the associations. For example, in the sample project you have ,. and each user can have multiple accounts. So when you issue a "run.bat deleteuser userA". In your code you need to make sure that you Iterate over the Accounts and delete them. But I believe that this need to delete all associations comes naturally to a developer. So it makes sense. 2. No need to manage table(s), schema, etc. - All I needed to do is either point to a datasource or a connection and it does the rest... This makes it nice for new projects and the naming of the columns makes sense and it's not rocket science. But I can see this being an issue in enterprise projects... Or in projects where the database comes before the application.... 3. Their support for transactions (MySQL) is nice... But I have not tested it. My only negative is that the column name be mapped to the variable name instead of the getter signature... I think if it finds a bean to map it to... it should use it and if it can't then map-to the getter signature... But over all this is an excellent tool for simple, quick prototyping of applications. Venkatt
  13. Ok... Round-2 : Simple But Not Sophisticated[ Go to top ]

    Ok... I decided to spend some more time on this pBeans and at first attempt it's simple but as you spend more time you start seeing some of it's idiosyncrasies... For example, let's take a simple example... you have and and you would like to have a property mapping the users favorite songs. Well the first challenge I hit was I tried the following: private List favoriteSongs; pBeans complains that it can't support this type and I need to mark this property/field as transient. So I'm forced to use primitives like Array[]... But that's fine... Now I changed my code to ... private Songs[] favoriteSongs; To my surprise when I added an array of songs... and I tried persisting... It turned out that pBeans saves it to a "BLOB"... This would work provided that I'm only working with pure Java based system... The minute you want to use pure SQL to do queries like how many people have selected a particular song as their favorite song... a simple query now can become very complex... since u are working with "BLOB"s... This was my experience... Any thoughts.... anyone?
  14. A algum tempo descobri um video tutorial totalmente em português sobre JPA produzido pelo Fabio Kung da Caelum, onde mostra passo a passo como utilizar essa biblioteca que é uma mão na roda de quem quer fazer mapeamento de objetos com banco de dados. Nesse tutorial é explicado desde os downloads dos jar necessários, configuração do banco de dados (mysql), utilização do jpa dentro do eclipse, geração das tabelas, etc, etc... dentre todos os videos tutoriais que já vi sobre java em geral, esse foi um dos melhores de todos. Muito bem explicado e detalhado. Para quem não conhece, JPA é a biblioteca usada de base para se construir os EJB Entity Beans, que fazem o papel de manter a integridade entre os objetos de entidade e o banco de dados. Mais uma vez, excelente tutorial! Parabéns Fábio! http://www.jornaljava.com/2008/11/video-tutorial-utilizando-jpa-com.html