RE: [OJB-developers] Kill the mapping files

[<ll...@li...>]

Thomas,

I think your "cost-benefit" argument is a very valid one.

The idea I have might be a good one on a longer term. But the
up-front-cost for refactoring might turn out to be too heavy.

Still refactoring the mapping files out would eliminate the task of
changing the mapping-file format.

Maybe the right approach is to hope and wait for a XML
PersistenceBrooker to come along and the refactor the metadata to use
that.

How about using the mapping api directly instead of using XML files. Is
that possible as OJB is constructed now ?

-----Original Message-----
From: Thomas Mahler [mailto:tho...@ho...]=20
Sent: 27. februar 2002 13:59
To: Lasse Lindg=E5rd
Subject: Re: [OJB-developers] Kill the mapping files


Hi Lasse,

Lasse Lindg=E5rd wrote:

> This might be a controversial suggestion. But it is an idea I got and
I
> would like to get some feedback on it.
>=20
> Wouldn't it be possible to just drop the XML mapping files.
>=20


Yes, this is definitely possible. The XML file is only one possible view

on the ojb.broker.metadata.DescriptorReposity.

In the early OJB days I build up the metadata programmatically or used a

Properties file.

A mapping tool should definitely only work on a DescriptorRepository=20
object and not struggle with input/output formats.
following this approach it will be possible to use several input/output=20
media for the metadata (e.g. XML, Properties-file, RDBMS, Java (XML-)=20
Serialization).


> The way I see it XML files contain data. And data should be persisted
in
> a database.=20


That's a good argument. I had also some thoughts in this direction.

> The way it is now the XML files are marshaled to OJB mapping
> objects which OJB then uses to figure out how to map the objects to
> tables.
>=20

> If we didn't have the mapping files it would be a easier to write the
> mapping-tool since it wouldn't require you to invent a tool to marshal
> and unmarshal mapping objects to xml files.
>=20



Unmarshalling from XML to ojb.broker.metadata is currently done by=20
ojb.broker.metadata.XmlRepositoryHandler.
The only thing currently missing is a marshaller. But this is quite=20
trivial to implement.


> Of course for this to be possible, there would have to be some kind of
> "bootstrapping" mapping objects that map the mapping objects to
database
> tables. That could be handled with a simple factory pattern that
returns
> hardcoded prebuild mapping objects.


I agree.


>=20
> One might argue that the current XML files are pretty simple to edit
in
> a text-editor. But I cannot see that it is significantly easier to
edit
> XML files than SQL scripts. And in the end the goal must be to build a
> visual (or better fully automatic) mapping tool.
>=20
> I hope my suggestion is clear enough.
> Would this be a possible way to go ?
>=20


Your suggestion has one advantage: OJB metadata can be persisted in the=20
same way as "ordinary" business objects.
Sure this is possible and also quite elegant. I like this kind of=20
"self-reference" !
But I see no REAL benefit apart from this:

But IMHO any serious mapping tool will work with DescriptorRepository=20
(and related) objects anyway.
Thus it will be faced with marshalling/unmarshalling only on=20
saving/loading repositories to work on.

I  think it will be simpler to write an XML marshaller than to get the=20
bootstrapping process working faultlessly.

It will be difficult for OJB novices to understand what's going wrong=20
when the metadata can not be loaded.

There is another possible problem: several people use multiple versions=20
of the xml repository for multipe applications they are running.
Working easily with multiple versions of the repository must be made=20
possible with your approach too.

You see I'm a bit ambivalent regarding you proposal. maybe we need some=20
more discussion or code experiments.


May be it would be a good idea to get first experiences with persisting=20
the OJB Metadata.
We could provide a DescriptorRepositoryFactory that can be configured to

either unmarshall the repository from XML or to load it from RDBMS.


thanks,

Thomas


> /Lasse
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
>=20
>=20
>=20