Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes forum!

Marco Masi

+ Follow
since Apr 18, 2009
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Marco Masi

If you want become a good java programmer the most important task is truly understand the oo paradigm. I've seen too many "java programmer" that don't understand it at all and always code in a procedural way (ok procedural isn't evil just isn't java!). Get a good book about it and study :P I would prefere a non language oriented book (i.e.: not a book about java but a book about oop). Unfortunately no good books come in my mind now

When you feel to understand OO the next lession in my opinion are programming patterns. They aren't obviously dictat but are good programming solutions (you could have use them without knowing :P).

About syntax... it depends on what you meaned. Java syntax isn't too hard...
But you meaned solutions and vaious api knowledge, isn't it? You'll learn using it, writing code, looking at other people code, reading documentation... just experience we could say.
11 years ago
You can call swap if you just need to... swap ( ) two known elements. If you need to sort the entire list just use sort (with or without comparator as I wrote before). You could write your own sorting algorithm but I wouldn't do it if not in real special cases, it handle sorting quite well.
11 years ago
Mmm the easiest way is use Collections utility and one of two:
implements Comparable it that sorting is the natural sorting of you object and use Collections.sort(List<T>)
write a custom Comparator and use Collections.sort(List<T>,Comparator<T>)

A comparator could be something like that (Date is already comparable ^__^)

11 years ago
The fast answer is: to not reinvent the square wheel.

ORM provides fast and easy ways to handle data stored on RDBMS hiding a huge part of this task complexity. JPA2 api is simple to understand and use and frameworks relieve you of lot of work. There are obviously drawbacks (you aren't really in complete control of database as you can be handling it by hand) but advantages outstrip them (nearly transparent transactions, JPQL standardized query language really object oriented...).

For medium and big projects I can't anymore think about use a database without an ORM... even for small projects I don't see a real advantage to use plain JDBC directly.

The propaganda of having to maintain Business Logic in the DB to avoid the possibility of moving from one DB vendor to another.
Moving to different DB vendors is a rare scenario in normal Business cases.

Yes DB vendor swapping doesn't happen very much (though I've already seen moving from MSSQL to MySQL and Oracle to MySQL... they were both cost cutting driven... and both a real pain in the ass) but I don't think that is the bigger reason to avoid as much business logic as possible on stored procedures. In my opinion changing a stored procedure is a much more delicate task than changing java code then better to go on the safest way.

I am unconvinced that, you can test only the ORM framework propaganda. Can't the StoredProcedures be tested? It is just that, the testing will have to be carried out in non-Java.

Probably stored procedures can be tested but surely is easier test java code (and for that probably it will be tested better too).

This is not a reason, not to use the power and efficiency offered by DB

Noone prevents you to get the best of both worlds... easy management for normal task and highly efficient procedures for that (really) small portion of code that need it (do you remember that "Pareto principle"?). But I have to admit that proceeding like that could lead to really ugly code...

Then, in my opinion, ORM (and frameworks in general) let the developer to focus on business logic shortening development time.
It was a very silly example i admit

Il'll take an example from the project I'm working on:

I have one entity rapresenting user data in the system (call that User) and another entity rapresentig some options setted from the user (call them UserOption).

User and UserOption are related in a 1:n relationship. When i access a User need to read UserOptions data so i mapped a OneToMany relationship User -> UserOption. It never happens in my logic to access some UserOption and look for owning user than i didn't mapped inverse ManyToOne relationship UserOption -> User.

If you don't need inverse relationship you could not map that (so you don't need to work on configuring inverse side... I make always mistake when I write them )

When using unidirectional or bidirectional relationship? (I hope it was the right question... )

I think it's all about your needings.

Personally i try to avoid bidirectional relationship if I don't need them so I can simplify mapping and entities.

You could have a simple Case - Pencil 1:n relationship where you need pencils in a particular case but you don't need where is a particular pencil.
But you could have a Customer - Bill 1:n relationship where you need all bills for a customer AND the customer of a particular bill.

Ok I know they were silly examples
Hi to all!

I was trying to implements relations in a entity hierarchy build using single table strategy but i had some strange problems that i can't resolve

I'm using:

Running a MySQL server 5.1.11.

This is the structure:

abstract MyBean with @Inheritance ( strategy = InheritanceType.SINGLE_TABLE )
MyBeanWithA extends MyBean and add a OneToOne eager relation with ABean (inverse side)
MyBeanWithB extends MyBean and add a OneToOne eager relation with BBean (inverse side)
ABean with a OneToOne eager relation with MyBeanWithA (right side)
BBean with a OneToOne eager relation with MyBeanWithB (right side)

Foreign keys on db need to be on ABean and BBean.
I need always to access MyBeanWithA when I access ABean.
I need always to access ABean when i access MyBeanWithA.
The same is for BBean and MyBeanWithB.

What I'm not capable to do is have an entity correctly loaded with his relation using polimorphism.

Here's the code (it isn't so beautiful but it's only demonstrative)








As you can see versions A and B are practically the same (much copy/paste )

Running this all (without log just to see) I get this (complete log in attach, try_1.log ):

loadedMyBean_A.getClass().getSimpleName(): MyBeanWithA
((MyBeanWithA) loadedMyBean_A).getBean(): ABean

loadedMyBean_BMyBean.getClass().getSimpleName(): MyBeanWithB
((MyBeanWithB) loadedMyBean_B).getBean(): null

loadedMyBeanWithA.getClass().getSimpleName(): MyBeanWithA
loadedMyBeanWithA.getBean(): ABean

loadedMyBeanWithB.getClass().getSimpleName(): MyBeanWithB
loadedMyBeanWithB.getBean(): BBean

I can't uderstand why using polymophism for MyBeanWithB I get a null reference, just for control loading MyBeanWithB without polymophism i get BBean correctly loaded

Looking for SQL it seems that BBean isn't considerated:

/* load my.entity.MyBean */ select
mybean0_.myBean_id as myBean2_2_2_,
mybean0_.bean_name as bean1_2_2_, as id0_0_,
abean1_.myBean_id as myBean2_0_0_,
mybeanwith2_.myBean_id as myBean2_2_1_
MyBean mybean0_
left outer join
ABean abean1_
on mybean0_.myBean_id=abean1_.myBean_id
left outer join
MyBean mybeanwith2_
on abean1_.myBean_id=mybeanwith2_.myBean_id

Instead setting relations on MyBeanWithX (i've changed optional from false to true)

The result is even worse in SQL BBean is now consierated but beans reference are null both for MyBeanWithA and MyBeanWithB (complete log in attach, try_2.log )

You have any suggestions?