Hi John, nice to here about your interest :-) Regarding 'Field', Sculptor doesn't (for the moment) have any out-of-the-box support. If it is natural key you are after, see: http://www.fornax-platform.org/cp/display/fornax/3.+Advanced+Tutorial+%28CSC%29#3.AdvancedTutorial%28CSC%29-Key
Then, regarding the similarities between Sculptor and UML2 cartridges and why we are not doing a joint venture. Well, we started of with different objectives. Sculptor tries to be a complete enterprise solution with a lot of QuickStart/RAD etc in mind. I.e. from your model you should have a complete, deployable, ready to go, crud application, from top down, GUI to DB. But, if what you are after is the ORM part, and you want to model it in UML, then I would point you to the UML2/Hibernate cartridge. We choose d not to use UML for our model since we find a little bit limited. You can't for instance model behavior or delegation in a smooth way. And we wanted to adapt the vocabulary of the http://domaindrivendesign.org/ DDD sphere. Thx, for the feedback and hope to see you in the source... .../Andreas jskillings wrote: > > Thank you Roland for clarification on the syntax. It worked like a > charm! > > I will review the oAW's xText capabilities and features. However, several > of the features and new Stereotypes I am interested like the Field, Key > Reference, Natural Key Reference etc. are already available in the > Hibernate Cartridge 1.4.1. > > I stumbled across Fornax and Sculptor this weekend, and already am > impressed with the product. But not knowing fully the integration plans, > my 2 cents are that it would be great if Sculptor team can leverage the > work of the UML2 cartridge team. No reason to have two separate efforts. > > This is all great stuff. I am looking forward to be an active contributor > to this forum. > > Best Regards, > > John > > > > rolandukor wrote: >> >> 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-tp14584877s17564p14593582.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
