Vista Combinata Vista Piatta Vista ad Albero
Discussioni [ Precedente | Successivo ]
toggle
Robert Dubecky
Service builder - relationships, problem with IDs
24 settembre 2013 5.35
Risposta

Robert Dubecky

Punteggio: New Member

Messaggi: 4

Data di Iscrizione: 18 agosto 2013

Messaggi recenti

Hello everybody,
I am very new to portals and generally Java EE, Spring, Hibernate etc., but now I have to create code for accessing and working with a database with around 25 tables and complex relationships.
Since I am new to all this stuff and I have to do it pretty quickly I was at first pleased with Service Builder and the possibility to create the base code with it. However the more I read about service builder the more I am confused.

1. A lot of people are complaining that there is not one-to-many relationships in service builder. But in Service Builder DTD there is written:
1
2If the entity and mapping-key attributes are specified and mapping-table is not,
3then the Service Builder will assume you are specifying a one to many
4relationship.


Also when I use this construction, I should get a class with a collection of objects from other table exactly how I would think ORM works.
So is there or isn't there support for one-to-many relationships in Service bulder and if there isn't, what is wrong with that construction or why can't I use it as one-to-many relationship?

2. I am having a problem when I define attribute called "id" in 2 different entities and then connect them through mentioned contruction (which is- I hope- one to many relationship). One of the generated persistance classes has syntax error using the same name for variables:
protected boolean contains(int id, int id)

Is there any way around it (if i dont want to rename all id attributes in all the tables to have different names) or am I doing something wrong?

3. Here I am asking for your educated opinion: should I use service builder for the mentioned databse (25 tables, a lot of 1-to-m, 1-to-1 relationships) or would it be better to do it myself, and in that case - what would you reccomend that I study and use if I have to do it as fast as possible?

Thank you all for your help.
David H Nebinger
RE: Service builder - relationships, problem with IDs
24 settembre 2013 7.24
Risposta

David H Nebinger

Community Moderator

Punteggio: Liferay Legend

Messaggi: 11334

Data di Iscrizione: 1 settembre 2006

Messaggi recenti

Yes, this should absolutely be done in SB.

1. these people think SB is an ORM, which it is not. Keep your entities simple and manage relationships in the code and you'll be fine.

2. you should always use a better name for the surrogates since you may need to do relationship mapping at a later point. Use parentId and childId instead of two id members.

3. SB is the way to go here.
Robert Dubecky
RE: Service builder - relationships, problem with IDs
24 settembre 2013 15.57
Risposta

Robert Dubecky

Punteggio: New Member

Messaggi: 4

Data di Iscrizione: 18 agosto 2013

Messaggi recenti

Thank you David, I was hoping for answer like that - SB could really save me a lot of time and studying all of these technologies right now.

Just for clarification in answer no. 1 - you wrote "Keep your entities simple and manage relationships in the code" -
1.Do you mean something specific by keeping entities simple?
2.And by managing relationships in code you mean that I can use that construction for 1-to-many relationships I mentioned earlier and just make sure that I always update entities from code when I change something using foreign key?
I mean like I have a collection of objects (mapped by foreign key) in my object and when I want to update them I should call their particular LocalService?

And just one more question I encountered trying to create my service.xml:
3.Is there any way to define one-to-one relationships in service.xml or do I have to do some workaround?
(like Jelmer is showing here: https://issues.liferay.com/browse/LPS-11479)

Thank you very much for your help!
David H Nebinger
RE: Service builder - relationships, problem with IDs
25 settembre 2013 8.20
Risposta

David H Nebinger

Community Moderator

Punteggio: Liferay Legend

Messaggi: 11334

Data di Iscrizione: 1 settembre 2006

Messaggi recenti

By keeping them simple, I mean avoid trying to model a relationship that you know is there.

For example, if you had an entity tied to the current user, you could try to get all fancy and do a parent-child relationship, etc. But what you'd quickly find is that SB will not export that very well.

Instead, if you used a simple column for userId and managed it within the code, you can still have your user relationship w/o trying to do it in the SB layer. Same thing applies for one-to-many and many-to-many relationships; put the necessary key columns into the entities but manage relationships on your own (i.e. yes, create the stupid entity for the join table of the many to many relationship and add the necessary methods to the XxxLocalServiceImpl class to facilitate whatever queries and updates you need to manage).

Managing the relationships in the code will prove to be much easier to support in SB-based code - yes you are manually managing entity relationships, but the SB code will be happy and external service consumers will be happy and everything will just work (as long as your relationship management code is correct emoticon).

This will sound like a total pain to folks familiar with ORMs (what, you have to manage your relationships manually in SB? what a piece of crap!), and that's when I have to reiterate that SB is not an ORM it is a tool to solve a different problem entirely...