Unfortunately, the parsing code sucks. It sucks because
(a) it was written to "do the job", not be elegant
(b) it uses DOM
(c) there are a lot of places where things are implied by a combination of
the mapping file and the class itself
We could fix (b) by chucking the whole .map package and re-doing it using
some databinding fwk. I'm not sure whats the best for databinding currently
though. I would actually very much like to do this, to get rid of ugly code.
However, currently the design of the map package has not been a problem for
_me_ in the functionality I've been concentrating upon.
(c) is more difficult since it means that plenty of perfectly legitimate
mapping files can't be fully compiled without the classes. However, if we
chucked + re-did with databinding, we would need a second-pass to fill in
reflected values *anyway*, so maybe there is also a way forward there.
Now, if it turns out to be worthwhile doing this, there is one thing working
in our favor. We have heaps of unit tests, so we shouldn't need to be
worried about breaking things.
----- Original Message -----
From: "Max Rydahl Andersen" <ma...@eo...>
To: "Gavin King" <ga...@ap...>
Sent: Monday, October 28, 2002 1:33 AM
Subject: Re: [Hibernate] Metadata, codegenerator et.al...
> > > Any suggestions on formats/semantics of it all ? (property and
attribute
> > are
> > > dubious names in
> > > this db context, so is custom-attribute a good tag-name/metadata name
> for
> > > it ?)
> >
> > How about <metadata name="foo" value="bar"/>
>
> So, we got a metadata to augment/describe the metadata - well, I suppose
> that's the
> way it is supposed to be :)
>
> > > I would love to contribute the above mentioned stuff, if I had a clear
> > > vision on the existing parsing and building
> > > of metadata info in Hibernate....and currently it seems that Hibernate
> > > CANNOT parse an hbm.xml without
> > > having the related classes in its classpath ...and that is somewhat of
> an
> > > limitiation when it is a codegenerator that
> > > is about to generate these classes :)
> >
> > Good point.
> >
> > > Anyone with a clear vision and understanding of hibernates hbm.xml
> parsing
> > > that can untangle that web of assumptions
> > > in the hibernate core ?
> >
> > Okay, there are two levels of metadata. The "parsed" metadata,
represented
> > by the cirrus.hibernate.map package and the "compiled" metadata which is
> > really just the internal state of the EntityPersisters.
> >
> > You have no chance of using the compiled metadata. On the other hand, it
> > would be reasonably easy to remove any references to actual classes from
> the
> > cirrus.hibernate.map package which is used to represent the internal
state
> > of Datastore. If you could clean up that package a little bit, it would
> > probably do what you want. Now, that package is definately not meant to
be
> > exposed to users, but you might be able to expose it to the toolset.
>
> I've tried to dig into the map package, but it seems there is waaay to
many
> places
> the code tries to do a classForName to check if it can continue to do its
> parsing -
> and by waaay to many, I mean waaay to many for me to go changing the parse
> semantics :(
>
> So, I'll try to "just" add the metadata tag stuff...that should be doable
> without changing much
> of the semantics, but it sure won't be as usable when the parser still
> requires the classes to
> be available ;(
>
> /max
|
