Brett Maclean

Greenhorn
+ Follow
since May 01, 2009
Merit badge: grant badges
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Brett Maclean

You should always free your inner obnoxious guy :-). But yes good point.
13 years ago
JSP
Hi Jone,

I'm not sure what your underlying schema is but can you not write the query using a join rather than a subquery:



Again, depending on your Hibernate mappings this relationship (between Quotes and Programs) may already be defined so you might be able to return the associated programs as a collection in your quote after filtering on the quote name. This of course will depend on your mappings, whether the association is set up, and which direction the association runs in.

HTH



Hi Agnit,

You just need to concatenate the prepared statement string properly. The way I'd do it is to create the string first, e.g.


and then plonk it in to the method of your connection.

HTH
13 years ago
JSP
Ah I see ... oh well, glad the "solution" is of use for a future problem! :-)
At the risk of being controversial I'd say that an interface defines behaviour whereas a class models a thing in the problem domain. The thing might be a generic and non-instantiable and hence an abstract class or it might have concrete objects but it's a thing nonetheless.

An interface defines what sort of operations the object performs e.g. move(), getCustomers(), drive() and hence is more about the object's capabilities (i.e. what it does) than its essence or what it is.

So I'd have to agree with them that an is-a relationship is really between two classes, but qualify that with the distinction is getting pretty philosophical / pernickety. But I guess that's object modelling in a nutshell ;-)
Hi Gene,

I'm not sure what your object model looks like, so this may or may not be relevant ;-)

It sounds as if you have an association within your Eventattendance class represented by another object and you want to query your results and restrict by some attribute in the associated class.

I've added an example below which hopefully is similar to your model. I have a User class {name, age, Address} and an Address class {house number, city, postcode} and the criteria query that I've added will find all Users that have User.name beginning with 'B' and User.Address.postcode beginning 'SE19' (both non-case sensitive)



Basically, you end up creating a criteria on User for the associated class (in this case Address) and then adding a Restriction on that Criteria to limit your Addresses to those that begin with the right postcode.

HTH
Yes, that's my point. They both inherit from a UserDao (which defines their behaviour). The splitting in to two separate implementation is to make it simple to inject and understand which data source the particular implementation is using.

I was also curious as to the use of two different data sources on top of the same (user) data. I was wondering whether this was due to implementing security rules in the database.
14 years ago
If I were you, I'd use separate DAOs to access the read-only and read-write data sources. This way you can inject the relevant data source in to each of the classes. You could even extend an abstract UserDao just to indicate that they both work on user data.

Just out of interest, why are they different data sources ? Is it down to the db privileges you've given to the user connections ? If so, this sounds as if a simpler solution might lead to less complexity in your code.
14 years ago
Ok, well the code below called the Javascript (to say hello) when I closed my browser window (I am using Chrome). This snippet is just an altered version of the code at the link I posted above.



My "close event" is the onbeforeunload event ... as I said above, JS isn't my strong suit but this certainly seemed to work. Now just replace alert('hello'); with a script that will call your server-side code. Best left as an exercise for the reader :-)
14 years ago
Hi Deepika

The <sql-update> element (along with the insert and delete) are for when you want your class-entity mapping to have DML that you define rather than Hibernate. So you will see these elements within a class mapping as per the code snippet at the top of this serverside.com article.

Reading between the lines, I'm not sure that this is what you are after. It sounds as if you just want to issue an update statement for a non-managed entity in which case you're probably better off having the UPDATE statement in a stored procedure and calling that. There's documentation on the Hibernate site about how to call stored procedures.

If however, you are issuing updates for a managed entity (i.e. one that you map via a <class> definition) then you will need to be careful as it's Hibernate's Sessions that need to be looking after the entity really. In this case, the best option is to use the custom update element within the class's mapping. The Hibernate link above goes on to describe how to do this.
In this case I think you will need to go back to the first option, of using Javascript to capture the close event and then either an AJAX request or a form submission to a servlet which will call your database state update code. I'm no Javascript expert but there is a suggested solution on Java Junction. Just as full disclosure, I haven't used this.

The other option, is the one that Jan suggested earlier.


What some applications (say: SAP) do, is,

when you log on, and it seems that you still have a log on active,
it allows you to choose:

a - stop this new log on : the new session closes.

b - stop the old log on, and allow the new session:
From that moment on, if the old session would still exist, the system would reject all activity in the old session, and only requests of the new session would be handled



Personally, I think this is preferable but maybe that's just my fear of Javascript talking :-)

14 years ago
Hi Lokendra,

You've also specified your SessionListener in the web.xml right - i.e. ?


<web-app>
<listener>
<listener-class>com.svc.session.Session_Invalidator</listener-class>
</listener>
</web-app>


When you say it isn't working, is it throwing an exception or does it not appear as if it's being called.

One last point ... it's always good practice to close JDBC resources in a finally statement.
14 years ago
Cameron's comments are spot on.

Also, is there another way that you can achieve what the requirement is ? I'm not sure what you're trying to do from a functional perspective, but if it's presenting to a UI then it's unlikely that your user will page through 600,000+ records (unless they are very patient or very bored :-). Maybe this is something that could be achieved through filtering (e.g. return all records where status = ACTIVE) or some kind of typeahead (e.g. return all records where username like 'Br%') rather than go for the whole result set ?

Either way you'll probably want to index the column you're performing the restriction on.
Hi Peter,

I think you are on the right lines. I think you're right about modelling them as subclasses etc. and the complexity of the joins being a drawback. Personally, I would implement ListPrice and UserPrice classes and map them via Hibernate but have no associations or hierarchical structure between them.

You can then load and cache the list prices if necessary. You're right that caching will increase the memory footprint, but this really depends on how much / what you cache. If you are just using it to look up prices then you could use the PKEY as the cache key and the price as the value. I'm not sure what other data you use or how often the prices change. If not much changes then maybe just look at having an in-memory representation of the prices as a lightweight object and use Hibernate to allow administrators to set new list prices etc (via Hibernate). Obviously this adds to the complexity in keeping the two lists synchronised, but shouldn't be too onerous.

Another option could be to denormalise the list price and hold this in each of the customer lists. This then moves the storage burden to the database layer but is also more complex in updating all the lists when the prices change.

HTH

Hi,

The Query class is meant for just that really, queries (i.e. SELECTs) rather than DML (inserts, updates, and deletes). That's why you're getting the error when you try to run the delete statement in your code snippet.

I'd echo Cameron's point above that Hibernate is meant to take away the grind of writing native SQL for you and moreover has a complex identity and session model that issuing standalone UPDATEs, INSERTs, and DELETEs will cause problems for (and that's why it doesn't allow you to do this in the Query interface).

There is a place for native SQL, but I'd say it's the course of last resort, where you are traversing large and/or complex relational structures that are better queried through optimised and tuned queries rather than an Object Relational layer. Hibernate like any good tool has the Query interface that you were using for this eventuality.