Hi Jskillins,
if you change this line
- @Emp manager <-> Emp
to
- @Emp manager nullable <-> Emp
then the generated schema for EMP_ID will be nullable. Attributes are not
nullable by default.
Q1: I dont know if sculptor precribes a a 'correct' way for modelling
parent-child relationships but i guess it depends a great deal on how you
intend to navigate the relationships. Standard OO best-practices might do.
Q2: Currently sculptor doesnt seem to enable customise the name of the field
generated using the DSL but if you are familiar with oAW's xText, then you
can as well use the AOP features to customise the code/schema/hibernate
generation for attributes. You may as well decide to even extend the DSL.
The developers guide provide information on how to do this.
Regards,
Roland
jskillings wrote:
>
> Hi all,
>
> Currently learning how to use Sculptor 1.2. I am trying to model a
> hierarchy relationship in DSL and need your help, as I am not sure how to
> enter the notation. It is a very simple Dept-Employee model with two
> entities.
>
> Entities
> -----------
> Department
> Employee
>
> Relationships
> --------------------
> 1) Each Department has one or more Employees
> 2) Each Employee belongs to one and only one Department
>
> 3) Each Employee may have one and only one Manager
> 4) Each Manager manages one or more Employees
>
> Dept / Employee is an One to Many Relationship
> Employee / Manager is also One to Many Relationship. This is a classic
> Parent-Child hierarchy relationship you will find in entities like
> Organizations etc. Typically the foreign key in these entities is null.
> A relational implementation is as follows: (Emp_ID number(10,0) not null
> primary key, Manager_ID number(10,0) null, foreign key (manager_id)
> references Emp (Emp_Id)).
>
>
>
> Here is my model.design.
>
> Application MyApp {
> basePackage=com.company
>
> Module HR {
>
> Entity Dept {
> !optimisticLocking
> !auditable
> String Dept key
> String Description nullable
> - Set<@Emp> Emp <-> Dept
>
> }
>
> Service EmpService {
> findEmpById => EmpRepository.findById;
> findAllEmps => EmpRepository.findAll;
> }
>
> Entity Emp {
> !optimisticLocking
> !auditable
> String EmpNumber key
> String firstname
> String secondname
> Date Birthday nullable
> - @Emp manager <-> Emp
> - Set<@Emp> Emp <-> manager
> - @Dept Dept <-> Emp
>
>
> Repository EmpRepository {
> findById;
> findAll;
> save;
> merge;
> delete;
> }
> }
>
> }
> }
>
>
> Issue
> --------
>
> 1) Not sure how to model the Employee Manager relationship in the DSL.
>
>
> Generated Table
> ------------------------
> Here is the generated table with the model design. The Manager foreign
> key
> is generated in the Employee as NOT NULL - which is wrong.
>
>
> DROP TABLE IF EXISTS EMP;
>
> DROP TABLE IF EXISTS DEPT;
>
>
>
> CREATE TABLE DEPT (
> ID BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
> DEPT VARCHAR(100) NOT NULL ,
> DESCRIPTION VARCHAR(100) ,
> CONSTRAINT UNIQUE (DEPT)
>
>
>
>
> );
>
> CREATE TABLE EMP (
> ID BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
> EMPNUMBER VARCHAR(100) NOT NULL ,
> FIRSTNAME VARCHAR(100) NOT NULL ,
> SECONDNAME VARCHAR(100) NOT NULL ,
> BIRTHDAY DATE ,
> EMP_ID BIGINT NOT NULL,
> *FOREIGN KEY (EMP_ID) REFERENCES EMP(ID),*
> DEPT_ID BIGINT NOT NULL,
> FOREIGN KEY (DEPT_ID) REFERENCES DEPT(ID) ,
> CONSTRAINT UNIQUE (EMPNUMBER)
>
>
> );
>
>
> Questions
> --------------
>
> 1) What is the correct way to model the parent-child hierarchy
> relationships
> in DSL?
> 2) Instead of a column like EMP_ID, is there a way to create a more
> friendly
> name like "MANAGER_ID" during the table generation.
>
>
> Appreciate if any one can respond to this email.
>
> Thank you.
>
> John
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Fornax-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>
>
--
View this message in context:
http://www.nabble.com/Sculptor-1.2%3A-Help%3A-Modeling-Hierarchy-Relationship-in-DSL-tp14584877s17564p14590155.html
Sent from the Fornax-Platform mailing list archive at Nabble.com.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Fornax-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fornax-developer
