[Mork]

Isn’t there any way that MYE4S can determine the parent objects from the database during scaffolding from tables?

Couldn’t MYE4S at least take a guess at what the parent objects are (and pre-check some) instead of dumping the entire decision process in my lap?

Looking at my ERD, it’s difficult to know exactly what the parent objects is/are.

For example, if you had the following relationship CUSTOMER has many ORDERS, then you’d say the CUSTOMER table was the parent object right? So, you’d check that one.

However, how about M:M relationships?

Often from a database it’s not obvious what all the parent relationships are.

Could you please add a tutorial with a M:M relationship and show how to scaffold that, including setting the “parent” correctly so the associations in the generated Java code are correct?

The existing tutorial only uses a single table so doesn’t really help that much in the real world.

Thanks,

– M

[jkennedy]

Mork,
I will send our product manager your request for a more in depth tutorial in this area, but I wanted to let you know that this wizard page is less complicated than it appears, and we are going to work on the way this question is presented to the developers in the flow of the wizard.

What we are really asking here is for you to UNCHECK any tables that are join tables (tables that only serve to join two other tables using foreign keys).
You can also optionally UNCHECK any tables that represent objects that you don’t to directly add/update/remove/delete on their own, but rather, you wish to only work with these objects through their relationships to other objects.

In my estimation, it is worth while to just uncheck join tables if you have any and leave the rest checked.
Then, if you don’t want the UI for managing certain objects to be available, you can always delete it later.

Let me know if this doesn’t make sense, sorry for the confusion. And yes, to answer your feedback, we should be selecting all of the tables for you by default.

Thanks,
Jack

[Mork]

Thanks Jack for your excellent reply.

I guess I’m still confused as to which check boxes, if any, that I should check.

Say you have a CUSTOMER table and an ORDERS table. Let’s say there’s a constraint from CUSTOMER:ORDERS which is the expected 1:M.

Now, when presented with the two tables in the wizard, would I check either one?

I’m trying to make sure I understand what you mean by “Parent” here.

I want to make sure that the Dao for the CUSTOMER table has the ORDERS table as a “Set” so Hibernate will know how to persist the data (and so I can populate the 1:M object correctly).

If I check neither box for the “Parent”, will I be messing up this aggregation relationship for the ORM framework?

Thanks in advance for your clarification here.

– M

[jkennedy]

Mork, in this case you should check both tables. To simplify the rule, check any table that actually stores data rather than just storing key relationships.

This will ensure that you get a CustomerService, CustomerDAO, and Customer Domain entity, as well as a OrdersService, OrdersDAO, and Order Domain object.
The Order and Customer Domain objects will have the relationships in them based on the way the DB is setup.

The UI will be generated such that you can see a list of Customers and then drill down, or see a list of Orders and then drill down.

If you had a table called customer_orders that had just two fields like:
customerid and orderid which was used to do a many to many join, you would want to UNCHECK this table so that we know not to create a Entity for it and that we should consider it a join table.

Hope this helps.
Jack

[Glen Ihrig]

Hi Jack,

This is a much needed explanation, it really helps.

To summarize, would it be correct to say:

Table checked – generate CRUD capability in the WEB and supporting layers.
Table not checked – generate relationship handling in the supporting layers only.

Thanks for clarifying this,

-Glen

[Mork]

Yes, this is a great explanation.

I would assume that the person who posted right above this posting has the interpretation correct.

It may be helpful, then, to change the text for “Selecting the parent” since this is confusing and really doesn’t describe what you’re doing.

Something like the person who posted right above me would be good:

Table checked – generate CRUD capability in the WEB and supporting layers.
Table not checked – generate relationship handling in the supporting layers only.

—-

Not sure how the current “Parent” text that’s in the wizard got there, but I’m extremely grateful for your excellent support!

🙂

— M

[jkennedy]

Thanks Glen, yes, much more concise summary.
We will work on this panel in the next release, or remove it all together.

Thanks for the use and ongoing feedback, it is very valuable.

Jack

[Author]

Posts