You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Marco Gattei <ma...@gmail.com> on 2011/11/11 12:57:59 UTC
Cayenne with JSF 2
Hi everyone,
I'm evaluating solutions for creating a back office application.
My usual choice in the past was Apache Click + Apache Cayenne, but needing
some really big sparkle on the UI, i was thinking about a JSF2 web
application with PrimeFaces.
But instead of using JPA + Hibernate i would really love using Cayenne.
Has anybody ever tried this solution or something similar ?
Thaks,
Marco
RE: Cayenne with JSF 2
Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.
Off-topic for the list but probably relevant for you:
I've been hearing lots of bad things about JSF and good things about Apache Wicket. I don't know anything about JSF2 or PrimeFaces though, so YMMV.
The good news is what others said: the presentation layer should be largely unaffected by the persistence layer.
Regards,
Jo
Re: Cayenne with JSF 2
Posted by Michael Gentry <mg...@masslight.net>.
Hi Marco,
I've not used JSF, but Cayenne should be relatively pluggable into any
UI framework you might be using. I personally use it with Tapestry 5
without any hassles.
mrg
On Fri, Nov 11, 2011 at 6:57 AM, Marco Gattei <ma...@gmail.com> wrote:
> Hi everyone,
>
> I'm evaluating solutions for creating a back office application.
> My usual choice in the past was Apache Click + Apache Cayenne, but needing
> some really big sparkle on the UI, i was thinking about a JSF2 web
> application with PrimeFaces.
> But instead of using JPA + Hibernate i would really love using Cayenne.
> Has anybody ever tried this solution or something similar ?
>
> Thaks,
>
> Marco
>
Re: Cayenne with JSF 2
Posted by René Aravena <re...@gmail.com>.
I am using cayenne + wicket 1.5 + wiquery (jquery in wicket == primefaces
look) + mysql and work fine.
René Aravena
2011/11/11 Marco Gattei <ma...@gmail.com>
> I knew about Cayenne behing 'really agnostic to the view layer' ....
> Cayenne is a truly gentlemen among ORMs !
> What i was wondering was if JSF would do be as nice with ORMs :-D
>
> Marco
>
> Il 11/11/2011 13:02, Andrus Adamchik ha scritto:
>
> Haven't used JSF2 myself, but Cayenne is really agnostic to the view
>> layer. If you've mastered JSF, you shouldn't have any trouble using Cayenne
>> with it.
>>
>> Cheers,
>> Andrus
>>
>> On Nov 11, 2011, at 2:57 PM, Marco Gattei wrote:
>>
>> Hi everyone,
>>>
>>> I'm evaluating solutions for creating a back office application.
>>> My usual choice in the past was Apache Click + Apache Cayenne, but
>>> needing
>>> some really big sparkle on the UI, i was thinking about a JSF2 web
>>> application with PrimeFaces.
>>> But instead of using JPA + Hibernate i would really love using Cayenne.
>>> Has anybody ever tried this solution or something similar ?
>>>
>>> Thaks,
>>>
>>> Marco
>>>
>>>
>
Re: Cayenne with JSF 2
Posted by Marco Gattei <ma...@gmail.com>.
I knew about Cayenne behing 'really agnostic to the view layer' ....
Cayenne is a truly gentlemen among ORMs !
What i was wondering was if JSF would do be as nice with ORMs :-D
Marco
Il 11/11/2011 13:02, Andrus Adamchik ha scritto:
> Haven't used JSF2 myself, but Cayenne is really agnostic to the view layer. If you've mastered JSF, you shouldn't have any trouble using Cayenne with it.
>
> Cheers,
> Andrus
>
> On Nov 11, 2011, at 2:57 PM, Marco Gattei wrote:
>
>> Hi everyone,
>>
>> I'm evaluating solutions for creating a back office application.
>> My usual choice in the past was Apache Click + Apache Cayenne, but needing
>> some really big sparkle on the UI, i was thinking about a JSF2 web application with PrimeFaces.
>> But instead of using JPA + Hibernate i would really love using Cayenne.
>> Has anybody ever tried this solution or something similar ?
>>
>> Thaks,
>>
>> Marco
>>
Re: Cayenne with JSF 2
Posted by Andrus Adamchik <an...@objectstyle.org>.
Haven't used JSF2 myself, but Cayenne is really agnostic to the view layer. If you've mastered JSF, you shouldn't have any trouble using Cayenne with it.
Cheers,
Andrus
On Nov 11, 2011, at 2:57 PM, Marco Gattei wrote:
> Hi everyone,
>
> I'm evaluating solutions for creating a back office application.
> My usual choice in the past was Apache Click + Apache Cayenne, but needing
> some really big sparkle on the UI, i was thinking about a JSF2 web application with PrimeFaces.
> But instead of using JPA + Hibernate i would really love using Cayenne.
> Has anybody ever tried this solution or something similar ?
>
> Thaks,
>
> Marco
>
Re: Cayenne with JSF 2
Posted by John Huss <jo...@gmail.com>.
On Tue, Apr 3, 2012 at 5:23 AM, yunus <co...@gmail.com> wrote:
> hi Andrus,
> I have two queries related to cayenne-
>
> 1- I have a table "registration" in which there is a primary key
> "EnrolmentId" which is autogenerated after successfully registration. Other
> attributes are "Name" and "PAN ID".(PAN ID can belong to more than one
> member of a family).So i want to know how i can find that a person cannot
> register more than once.I want to find through combined search of (Name &
> PAN ID) but these are not composite key as Enrolment id is already a
> primary
> key.Now can you tell me how it can be done using Cayenne.
>
You do this by adding a UNIQUE constraint to your database for these
columns. That is the only way to truly enforce it.
John
Re: Cayenne with JSF 2
Posted by John Huss <jo...@gmail.com>.
On Tue, Apr 3, 2012 at 9:09 AM, yunus <co...@gmail.com> wrote:
> Thanks mike, i'll refer your code.
>
> Can you tell me how can we relate primary key of one table to other such
> that if primary key of one table is autogenerated then primary key of other
> table gets automatically filled with the same data.
http://cayenne.apache.org/doc/to-dep-pk-checkbox.html
Re: Cayenne with JSF 2
Posted by yunus <co...@gmail.com>.
Thanks mike, i'll refer your code.
Can you tell me how can we relate primary key of one table to other such
that if primary key of one table is autogenerated then primary key of other
table gets automatically filled with the same data.
--
View this message in context: http://cayenne.195.n3.nabble.com/Cayenne-with-JSF-2-tp3499495p3881043.html
Sent from the Cayenne - User mailing list archive at Nabble.com.
Re: Natural primary keys, Was: Cayenne with JSF 2
Posted by Mike Kienenberger <mk...@gmail.com>.
We're not talking about whether or not a SSN uniquely identifies a person.
We are talking about the process for changing up an
incorrectly-entered natural primary key, for whatever reason that
might be.
On Wed, Apr 4, 2012 at 9:36 AM, Durchholz, Joachim
<Jo...@hennig-fahrzeugteile.de> wrote:
> Seems like everybody is looking at the institutions that can't keep their numbers constant.
>
> Give it a break.
> Ordinal numbers of chemical elements cannot change, by definition.
> I may be too optimistic about ISBNs and EANs. Haven't dealt with them and don't know how reliable their issuers are. I guess if they are using their own numbers in a PK in any table that's moderately important, they should catch any duplicates before they make it into the wild. SSNs are issued decentrally, so I'm not surprised they aren't unique; ID cards are issued centrally and managed centrally, so the risk of getting caught in a goof-up is considerably smaller.
>
> Oh, and if you're a company caught in the SSN goof-up, using a synthetic key wouldn't have helped in the least. There is no better ID available when it comes to US citizens, so if you're using data from external sources, your data will be goofed up anyway.
> Things are different if you never use the SSN in external communication to other databases. However, even then you'll never know whether the persons with the same SSN are the same (just changed name and location) or not; there's no better way to identify US citizens, and a synthetic PK won't help you much to resolve that kind of issue!
RE: Natural primary keys, Was: Cayenne with JSF 2
Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.
Seems like everybody is looking at the institutions that can't keep their numbers constant.
Give it a break.
Ordinal numbers of chemical elements cannot change, by definition.
I may be too optimistic about ISBNs and EANs. Haven't dealt with them and don't know how reliable their issuers are. I guess if they are using their own numbers in a PK in any table that's moderately important, they should catch any duplicates before they make it into the wild. SSNs are issued decentrally, so I'm not surprised they aren't unique; ID cards are issued centrally and managed centrally, so the risk of getting caught in a goof-up is considerably smaller.
Oh, and if you're a company caught in the SSN goof-up, using a synthetic key wouldn't have helped in the least. There is no better ID available when it comes to US citizens, so if you're using data from external sources, your data will be goofed up anyway.
Things are different if you never use the SSN in external communication to other databases. However, even then you'll never know whether the persons with the same SSN are the same (just changed name and location) or not; there's no better way to identify US citizens, and a synthetic PK won't help you much to resolve that kind of issue!
Re: Natural primary keys, Was: Cayenne with JSF 2
Posted by Michael Gentry <mg...@masslight.net>.
Maybe your government doesn't goof up social security numbers, but
ours does. :-)
http://www2.nbc4i.com/news/2010/dec/06/2/study-finds-millions-duplicate-social-security-num-ar-316988/
Also, don't forget that if a social security number (let's assume the
government never messes up and assigns the same number to multiple
people) is entered by hand and is used as a natural primary key, there
is a non-zero chance that the person entering the number will mistype
it and you've just messed up your keys and have a mess to clean up.
mrg
On Wed, Apr 4, 2012 at 5:32 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> Yes a government tax number or social security number is unique and
> immutable. And that would be true only if your database table was a table
> representing social security numbers. Instead it probably represents
> 'people' and then the correlation becomes far less certain. Do government
> departments ever make mistakes? Do they reassign numbers to people in a
> witness protection program?
Natural primary keys, Was: Cayenne with JSF 2
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 4/04/12 7:06 PM, Durchholz, Joachim wrote:
>> However any time you have a primary key with meaning is probably
>> a mistake in database design. You are best trying to avoid this
>> at all costs unless you are constrained by a legacy system in
>> some way.
>
> This is common advice, but the topic is controversial.
> Even in non-legacy databases, having natural PKs can have advantages:
[snip]
I take your points, but almost anything that looks like a natural key... rarely is. Back when I developed systems for other people, I could not count the number of times a customer guaranteed that a certain value would never ever change. Ever. And of course it did.
People who aren't programmers have a more relativistic concept of "never". To them, getting hit by lighting is "something that just never happens". If it happens once every 5 years, that might also qualify as "never". To them, your question simply means "so rare as to be not important to their daily lives". But of course there is a situation when that EAN isn't unique. When an ISBN is accidentally used twice for the casebound and software editions (they should be different). For a programmer unique and immutable have a special absolute meaning.
Yes a government tax number or social security number is unique and immutable. And that would be true only if your database table was a table representing social security numbers. Instead it probably represents 'people' and then the correlation becomes far less certain. Do government departments ever make mistakes? Do they reassign numbers to people in a witness protection program?
Maybe there are exceptions. I can't think of any. At any rate, once you give yourself over to an ORM (Cayenne or anything else), the agreement you make with the software is "Give me objects and don't bother me with how they are stored." SQL with a primary key or 12 chimpanzees with punch cards, it doesn't matter. Sure you can open the hood and tinker with the engine. But if you just want to just drive the car, primary keys are not something that should be exposed in your Java code.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
RE: Cayenne with JSF 2
Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.
> However any time you have a primary key with meaning is probably
> a mistake in database design. You are best trying to avoid this
> at all costs unless you are constrained by a legacy system in
> some way.
This is common advice, but the topic is controversial.
Even in non-legacy databases, having natural PKs can have advantages:
- A synthetic key often means an additional join since an internal ID number is incomprehensible to a human so you need to get the database record that contains the printable text for the ID. This affects a large percentage of queries that return displayable data, and almost all ad-hoc queries that your team leader will use to check database sanity (this means that your team leader will usually shoot down the idea of using synthetic PKs exclusively, with good reasons, and that's that).
- Even with synthetic keys, in a hierarchy of parent-child relationships, it is useful to construct the PK of a child from the ID of the parent plus a unique synthetic detail id. That way, if you have a grandchild record, you can immediately access its grandparent and don't need to load the parent record. This isn't a very common scenario and mostly restricted to ad-hoc queries, but it does occasionally help.
- A synthetic key is redundant if the data does contain a natural key, so we're violating a normalization property and (more importantly) spreading out the data over more disk sectors, which has a performance impact (this starts to get noticeable at six-digit record count and can become paramount at millions of records; below that, performance is usually a non-issue anyway and you need to question yourself what you actually need a database for when a text editor search will work just as well - okay, I'm exaggerating a bit :-) ).
There is one restriction: You never ever change a primary key. It's technically possible, but in practice, you need to find each and every place where that key value was ever stored: not just associated tables but also any database dumps on backup media, or if that PK value ever went to somebody else's computer (say, via a webservice), any copy of the value on their disks, which is far more effort that it's worth even if you manage to control all the places where the value has gone.
So, if you use natural keys, if there is *any* chance that *anybody* will *ever* want to change a PK candidate field, don't put that field in the PK and use a synthetic PK instead.
The distinction between natural and synthetic keys is a bit more blurry than most people realize, too. Most "natural" keys that I see in practice have started life as synthetic key on somebody else's system.
The EAN, ISSN, and ISBN, for example, come as data to most, but these are a world-wide unique values specifically designed to never change, so each of them is perfectly fine as a PK if you are dealing with data that always comes with such a number. Just be 150% sure that all the articles you'll ever deal with are guaranteed to have such a number (not true if you're doing business with entities that do not know or care about such numbers, but can be true in B2B scenarios).
The symbols of chemical elements, despite being standardized, have changed in the past, and it is conceivable that we may live to see one or two changes in the future. Ordinal numbers of elements, by definition, never change, so they are an acceptable PK in a table of element properties.
If you are talking to another system and that system provides you with a unique key for something, you can use that UK as a PK (or as part of a PK), too. Just talk to the guys maintaining the system and make sure that they run a strict never-change-a-PK policy. (This is essentially the same scenario as the one with EAN/ISSN/ISBN, except that the guys maintaining these PKs have already publicly committed to never changing these numbers.)
Reporting straight from the trenches,
Jo
Re: Cayenne with JSF 2
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 4/04/12 4:49 PM, yunus wrote:
> How can i prefix primary key with any alphabet like Admin121?
This is going to be quite a lot of work to do since any automated mechanism in Cayenne or in the db will work on integer values only.
If you are trying to avoid namespace collisions with some other system, you might be better off with a compound primary key and managing that by hand.
However any time you have a primary key with meaning is probably a mistake in database design. You are best trying to avoid this at all costs unless you are constrained by a legacy system in some way.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Cayenne with JSF 2
Posted by yunus <co...@gmail.com>.
How can i prefix primary key with any alphabet like Admin121?
--
View this message in context: http://cayenne.195.n3.nabble.com/Cayenne-with-JSF-2-tp3499495p3883336.html
Sent from the Cayenne - User mailing list archive at Nabble.com.
Re: Cayenne with JSF 2
Posted by Mike Kienenberger <mk...@gmail.com>.
On Tue, Apr 3, 2012 at 6:23 AM, yunus <co...@gmail.com> wrote:
> I have two queries related to cayenne-
It would be best if you changed the subject and started a new thread
for each new topic.
> 1- I have a table "registration" in which there is a primary key
> "EnrolmentId" which is autogenerated after successfully registration. Other
> attributes are "Name" and "PAN ID".(PAN ID can belong to more than one
> member of a family).So i want to know how i can find that a person cannot
> register more than once.I want to find through combined search of (Name &
> PAN ID) but these are not composite key as Enrolment id is already a primary
> key.Now can you tell me how it can be done using Cayenne.
1 - there are many different ways to do this. See this url.
http://cayenne.apache.org/doc/queries.html
I would generally do it with a SelectQuery. Something along these lines:
Expression nameExp =
ExpressionFactory.matchExp(Relationship.NAME_PROPERTY, providedName);
Expression panIdExp =
ExpressionFactory.matchExp(Relationship.PAN_ID_PROPERTY,
providedPanId);
Expression qualifierExpression = nameExp.andExp(panIDExp);
SelectQuery query = new SelectQuery(Registration.class, qualifierExpression);
Note that if PanId is a foreign key to a Pan record rather than a
number, you would do this instead:
Expression panExp =
ExpressionFactory.matchExp(Relationship.PAN_PROPERTY,
providedPanObject);
Please note that andExp() RETURNS the combined expression. It will
not modify the first expression. A common mistake is to use
"e1.andExp(e2)" instead of "e3 = e1.andExp(e2)". The value of e1
will not change.
And lastly, if it's not obvious from the docs, you can put these all
together if you desire.
Expression qualifierExpression =
ExpressionFactory.matchExp(Relationship.NAME_PROPERTY,
providedName);.andExp(ExpressionFactory.matchExp(Relationship.PAN_ID_PROPERTY,
providedPanId););
> 2-How can i restrict cayenne to autogenerate the primary key.The scenario is
> that i have a table "LOGIN" in which "UserID" is primary key and i dont
> want it to be generated automatically.It is upto the user to create his
> "userID" so how can i do that?
2 - You can set this in the Cayenne Modeler. Just turn off primary
key generation and add the loginId attribute directly to the
ObjEntity. At this point, you are responsible for assigning a value
to it.
However, this is a not the best design. You are better off creating
a meaningless login_id primary key in your table and not using UserId
as your primary key. What happens if you have a user who has a
userId needs to be changed? You will have to find every reference to
that user id in your database and change it. This might happen
because you later on want to allow users to update their userid, or it
might happen because a userid has an unacceptable value (obscene, for
example). It is better to make userId a regular field in your table
and simply check for uniqueness when creating them.
Re: Cayenne with JSF 2
Posted by yunus <co...@gmail.com>.
hi Andrus,
I have two queries related to cayenne-
1- I have a table "registration" in which there is a primary key
"EnrolmentId" which is autogenerated after successfully registration. Other
attributes are "Name" and "PAN ID".(PAN ID can belong to more than one
member of a family).So i want to know how i can find that a person cannot
register more than once.I want to find through combined search of (Name &
PAN ID) but these are not composite key as Enrolment id is already a primary
key.Now can you tell me how it can be done using Cayenne.
2-How can i restrict cayenne to autogenerate the primary key.The scenario is
that i have a table "LOGIN" in which "UserID" is primary key and i dont
want it to be generated automatically.It is upto the user to create his
"userID" so how can i do that?
--
View this message in context: http://cayenne.195.n3.nabble.com/Cayenne-with-JSF-2-tp3499495p3880428.html
Sent from the Cayenne - User mailing list archive at Nabble.com.
Re: Cayenne with JSF 2
Posted by Andrus Adamchik <an...@objectstyle.org>.
Not a JSF user myself, but the use of Cayenne is not that much different between various frontends. You've probably seen the webapp Cayenne tutorial at http://cayenne.apache.org/doc30/tutorial.html You can just follow that on the Cayenne end. You will need to find a similar introductory resource for JSF. I am sure there's plenty of them.
Andrus
On Mar 29, 2012, at 12:39 PM, yunus wrote:
> Hi..i am developing a web application using JSF and Cayenne and i am pretty a
> beginner with cayenne technology. So can anyone tell me what will be the
> data flow from presentation to persistence process and what type of class
> will be created during this web application like entity,managed bean
> etc.Please give me detailed description about it and if anybody has related
> web application then please send me...
> i'll be very thankfull to all of you.
>
> --
> View this message in context: http://cayenne.195.n3.nabble.com/Cayenne-with-JSF-2-tp3499495p3867223.html
> Sent from the Cayenne - User mailing list archive at Nabble.com.
>
Re: Cayenne with JSF 2
Posted by yunus <co...@gmail.com>.
Hi..i am developing a web application using JSF and Cayenne and i am pretty a
beginner with cayenne technology. So can anyone tell me what will be the
data flow from presentation to persistence process and what type of class
will be created during this web application like entity,managed bean
etc.Please give me detailed description about it and if anybody has related
web application then please send me...
i'll be very thankfull to all of you.
--
View this message in context: http://cayenne.195.n3.nabble.com/Cayenne-with-JSF-2-tp3499495p3867223.html
Sent from the Cayenne - User mailing list archive at Nabble.com.
Re: Cayenne with JSF 2
Posted by Mike Kienenberger <mk...@gmail.com>.
I have a Cayenne 1.2 + JSF 1.1 app I still maintain. It works well.
There's really nothing special required to hook up JSF and Cayenne.
On Fri, Nov 11, 2011 at 6:57 AM, Marco Gattei <ma...@gmail.com> wrote:
> Hi everyone,
>
> I'm evaluating solutions for creating a back office application.
> My usual choice in the past was Apache Click + Apache Cayenne, but needing
> some really big sparkle on the UI, i was thinking about a JSF2 web
> application with PrimeFaces.
> But instead of using JPA + Hibernate i would really love using Cayenne.
> Has anybody ever tried this solution or something similar ?
>
> Thaks,
>
> Marco
>
Re: Cayenne with JSF 2
Posted by Marek Šabo <ms...@buk.cvut.cz>.
Hi,
my team deployed Cayenne in solutions with Wicket, JSF2 and Primefaces.
From our experience, integration with Wicket is easier, colleagues who
worked with JSFs relied heavily on DTOs, in Wicket, you need them
seldom, you can use ValueMaps and properties that Cayenne provides,
either way it's very nice, very few hiccups.
Regards,
Marek
On 11/11/2011 12:57 PM, Marco Gattei wrote:
> Hi everyone,
>
> I'm evaluating solutions for creating a back office application.
> My usual choice in the past was Apache Click + Apache Cayenne, but
> needing
> some really big sparkle on the UI, i was thinking about a JSF2 web
> application with PrimeFaces.
> But instead of using JPA + Hibernate i would really love using Cayenne.
> Has anybody ever tried this solution or something similar ?
>
> Thaks,
>
> Marco
Re: Cayenne with JSF 2
Posted by Christian Grobmeier <gr...@gmail.com>.
Hey Marco,
I have used Cayenne with Wicket without pain: http://bit.ly/rD7BOJ
And the migrated from Wicket to Struts. Cayenne is still in place.
>From web interface layer I always felt JSF pretty painful and obscure.
Today I would take a look into Vaadin:
https://vaadin.com/home
Which is succeeding were Wicket fails, imho.
With Vaadin is better to use when it comes to custom css/javascript.
Or the old but still great Struts.
Anyway Cayenne was always a good choice to me.
Cheers,
Christian
On Fri, Nov 11, 2011 at 12:57 PM, Marco Gattei <ma...@gmail.com> wrote:
> Hi everyone,
>
> I'm evaluating solutions for creating a back office application.
> My usual choice in the past was Apache Click + Apache Cayenne, but needing
> some really big sparkle on the UI, i was thinking about a JSF2 web
> application with PrimeFaces.
> But instead of using JPA + Hibernate i would really love using Cayenne.
> Has anybody ever tried this solution or something similar ?
>
> Thaks,
>
> Marco
>
--
http://www.grobmeier.de