I'm trying to do what seems like it should be very simple. Please disregard the inappropriteness of the class names since I hacked my helloHibernate and simply added a list of speakers to my message class so that I could isolate this into a simple example. What I want is java.util.Map style collection in which I can use the String speakerId to access the HashMap. I want the table of MESSAGES to have a text column named XSPEAKER_ID to look up a speaker in the table SPEAKERS using the text column SPEAKER_ID

Ideally, the SPEAKERS table (in this example) would have two columns (SPEAKER_ID, SPEAKER_NAME) and the MESSAGES TABLE would have one column (XSPEAKER_ID) in addition to it's other columns. (I used "XSPEAKER_ID" to not confuse with "MSPEAKER_ID" in the SPEAKERS table that I currently have.

The mappings you see below is a work in progress as I attempt to figure out what names relate to what tables and such.

I tried to use the mapping description on the bottom of p134 of Hybernate Quickly exactly as is, and it wouldn't make it through the parser.

If anyone has a simple example of a java.util.Map which shows the class declarations, the mapping, and the session code, I would appreciate it.

Thanks,

Stephen Smith

pertinent part of classes:


Hibernate version: Version 3.1.2

Mapping documents:
Messages:

Speaker:


Code between sessionFactory.openSession() and session.close():
public void addSpeaker(Speaker _speaker) {
Session session = getSessionFactory().openSession();
Transaction tx = session.beginTransaction();
spkr.put(_speaker.speakerId, _speaker);
session.save(this);
tx.commit();
session.close();
}

Name and version of the database you are using:
MySQL 4.0.20

You haven't set the table name in the map, so it'll be looking for a table called "spkr". Could that be it? If not, can you post your full error/exception text.

No, that's not the problem. There's no error trace. I didn't post the output because I'm still fumbling around trying to get it to do what I want it to do which is to behave exactly like a java.util.Map. So rather than post some code for someone to debug, I tried to post my attempt to define the classes and the mapping which I thought was right and see if someone else has faced and conquered a similar problem.

Currently I'm able to get it to add items to my Speakers table, but it is not updating my Messages table, and it puts in a third column in my speakers rather than the two that I want.

Stephen Smith

I wouldn't have your hibernate mapping generate your schema, yet. That just means you've got two potential sources of error, making it much harder to find what's going wrong. Get the mapping right first, using tables that you've created. You can change it to generate the schema later.

Anyway, assuming that you want a one-to-many association (no join table):I notice that you're using SPEAKER_ID twice, and both times it's referred to via a column="SPEAKER_ID". You can't map a column twice, so you have to use formula="SPEAKER_ID" once. Do this in the map-key, so that the speaker class remains in control of its own ID.

Thanks for your suggestions, but I don't fully understand them. You say


I think you mean, just define a skeleton class, then create a mapping file. Correct? Next you suggest a mapping, but it in incomplete. This is part of my problem. I haven't figured out exactly what is needed in the mapping file. Here's what I've tried for the mapping

When I coded this, I go the errors


Yes, I want a one-to-many. Think of it as a persistent implementation of java.util.Map.

Actually, I meant that you should create the tables, columns, etc. in your database: you shouldn't have hibernate do it for you. I was picking up on your earlier statement:

I was suggesting that hibernate should not be putting columns anywhere. You should set up all the columns first.




That's an easy one to fix. type doesn't work for map. Remove it. The only attribute other than name that's useful is table, and you don't need that in this case (it's used when there's a join table involved).





A many-to-many is also a persistent implementation of java.util.Map. But cool, we'll work with one-to-many. You almost have it now. Just keep looking at the errors that Hibernate provides for you. Not all of them are intuitive, but in most cases you should be able to figure out the next step.

I did start with my database schema. The only reason that I added the other columns was to attempt to make Hibernate happy.

Dropping "type" from map made the first error go away, but the second one didn't. In the past, I've found that the error


is misleading.

The reason that I'm posting a question is that I found that the books that I've been referring to don't actually try the examples, the examples are out date, or they just give a snippet and assume that you know what they left out. I'm using "Hibernate Quickly", "Hibernate in Action", Oreilly's Hibernate Developer's Notebook, and the Manual that comes with Hibernate. Does anyone have a suggestion of a better reference that has some simple examples of each concept that actually run?

For working examples, download Caveat Emptor, Hibernate's test app.

Messages of the form "The content of element type "class" must match "(meta*,subselect?..." mean that you've got something out of order. For example, in classes, sql-query and query must come after the properties, sets, many-to-ones, etc., which in turn must come after your id declaration. If you define a query then a property, you get that kind of message.

Messages of the form "Attribute "type" must be declared for element type "map". " mean that the mentioned attribute is illegal and does not work for the given element.

When you see these messages, have a go at reading the DTD (in the source directory, it's in org/hibernate/hibernate-mapping-3.0.dtd). You don't have to understand it particularly well to figure out what elements allow what attrbiutes, and their order.

Right, back to your issues. You've created your schema: if you're confident that it will correctly model what you need, don't change it just for hibernate: it's better to change your mapping to work with the schema. For one thing, hibernate gives useful (if sometimes slightly cryptic) error messages that will change every time you change the mapping, giving you new hints as to what's wrong. Changing the schema won't do that.

I'd say you're very close to having it work: if your only error now is the one you've mentioned, then you just have to re-order your mapping statements to follow the rules in the DTD. Once that's done, hopefully you'll have a working mapping.

I tried once to get Caveat Emptor running, but I was fighting other issues. I'll take your suggestion and try it again. Your suggestions were helpful. I'll taket them into account. I guess I'd better brush off my XML books. I haven't spent a lot of time with DTD files, but I don't remember them being all that complicated.

I've spent a lot of time designing SQL databases, hand coding SQL queries and using JDBC, so I'm pretty sure that I've got the schema I want. I'll go back to it and beat on Hibernate until it starts behaving.

I'm going out of town for a few days, so I may not get back to you much after tonight until next week.

I now have a simple example and it's starting to work, but still has problems. (See below) I have two classes ParentClass and ChildClass. ParentClass uses a java.util.map to hold all the children.

ParentClass


ChildClass


Database schema


ParentClass.hbm.xml


ChildClass.hbm.xml


The First Error


The Second Error -- The most important one to solve

Looks like you've got your columns messed up. Your FKColumnInParentTable column is obviously supposed to be joined with ChildId, but ChildId is auto_increment, which makes me think that you want it to be unique for each row in the Child table. Unique per row is good: your problem is that FKColumnInParentTable should eliminated, and a parentId column put into child. That way you can have many children for one parent: your current mapping seems to prevent that (given a parent with FKColumnInParentTable = 1000, and at most one row in Child with id = 1000 (it's autoincremenet), that means the map in parent can have at most one child).

The parent table needs no references to child at all, though it can have an id to be used just for the map. Normally, the table's primary key is used for this. The Child table needs at least two "key" columns, one for the parent id, and one for the map-key. The child may have its own, separate, primary key, or use parentId + mapkey = primary key.

In the <map> element, the <key> element must refer to the column in the parent table, which is often the parent's primary key. <map-key> refers to the distinguishing column in the child table usually the distinguishing part of the child's primary key.

You were right, my tables were screwed up. I don't need a parent table. I only need a child table and I don't need any links back to the parent. Remember what I'm trying to accomplish is to persist a java.util.Map. My child table needs 3 columns: An id which is auto incremented, a childKey which is the key by which I will access it, and text which represents the information for a child. So here is the schema:

I'm afraid I let my database issues creep back into my code. So now the ParentClass is really just the container which gives me access to all the entries in the java.util.Map which is persisted in the table CHILD. There is never a need to find ParentClass given a ChildClass. So how do I tell this to Hibernate? I.E. What does the ChildClass.hbm.xml file look like. Do I need a ParentClass.hbm.xml file? If so what does it look like? What do the properties of ChildClass look like? Here's what I think they look like.

ParentClass.hbm.xml
???

ChildClass.hbm.xml


ParentClass.java


ChildClass.java


I know that somewhere I need a <map> to specify the mapping, but I'm not sure how to do it since I don't need a PARENT table.

If you're hoping to just persist a Map, with no class that owns that map, then I believe that you're heading about this the wrong way. Hibernate persists classes (which may contain collections of objects, but are not themselves collections), so if you wanted to do that you'd have to make a Map implementation and define a mapping for it. But then you'd be losing out on all the work that the Hibernate team did for you wrt persisting maps.

Let me give a (weak) example; if you've got an example rather than the abstract stuff you've talked about so far, I'm happy to work with that, too.

Let's say you want to persist a map of authors to books. Your last post suggests to me that you have a requirement that the implementing class implements the Map interface. You'd want an AuthorMap, where authorMap.get("Stephen King") would return "It", "Carrie", etc. The problem with that model is that you can't use any pre-written Map implementations, or the <map> element provided by Hibernate. You'd have a class that grabs all the rows from the DB and serves them up on request. It also means that there's no concept of nesting: anyone who looks in your Map would be able to see everything, rather than just everything that they put in the Map.

If you can find a suitable parent object for your Map, then all of that goes away. If you had a Library class that had a getAuthorMap() method, then you'd fit in with the way the <map> element has been designed. The AuthorMap table would have a libraryId, so that you'd know which books were in which library; and obviously it would still have an Author column and a Book column. You may also choose to give it a separate unique id, bookId, though that's not necessary.

If you can't find that suitable parent object for your map, then you can't use the <map> element. You can still have your implementing class implement the Map interface, but you won't be able to use HashMap or any other concrete implementation "out of the box". You'd probably be best off simply extending AbstractMap and implementing the work methods yourself.

If you're certain that you want to persist a Map as a top-level object, then I can expand on what you'd need to do in my next post. But I think it would be better to find appropriate parents for all of your maps, so that you don't have to reinvent the wheel.

I do have a class which owns the map. It's called ParentClass. I just don't need a table of ParentClass because there is only one. Let me give you my concrete example.

I have a list of members in my club. I don't care if they belong to other clubs. As far as I'm concerned, I'm only interested in a list of members. I want to allow them to login to my web site so I assign them a loginName and a password. So I create a table in my database called MEMBERS which contains an id, a loginId, and a password. (of course I'm simplifying this since I will keep lots more information about each member). In my class called DbMain I have a property:

private java.util.Map members = new HashMap();

The objects in members are objects of the class ClubMember. ClubMember has properties:

private Long id; // MEMBERS column id
private String loginId; // MEMBERS column LoginId
private String password; // MEMBERS column Password

Now when they attempt to login, have to look in members to get ClubMember which has the matching loginId. Now I can check the password. I don't see any need to have a table in my database corresponding to DbMain, nor do I see any reason for members having a link to DbMain.

This is exactly analogous to the ParentClass/ChildClass that I described earlier. I just changed the names so that it was clear that there was no idea of multiple Parents. Can you give me an example of the hbm.xml files that are needed to implement this?

Sure. I'm slightly confused as to why ClubMembers is in a class called DbMain: it should be in the Club class. I'll move it there for my purposes.

Club table has ClubId primary id, other columns unimportant.
ClubMember has the three columns you mention and the vital column that refers to the club to which the member belongs. This is the important point I was trying to make in my previous post: if a ClubMember doesn't have an owning club, then you can't make use of the <map> element.

Here are the salient parts of the mapping.