Thread: RE: [OJB-developers] Kill the mapping files
Brought to you by:
thma
Menu
▾
▴
objectbridge-developers
|
From: Christian S. <nc-...@ne...> - 2002-02-27 09:38:38
|
Lasse, you got me wrong. I did not mean to let OJB map to XML as it does to RDBMS. All I tried to say is that the storage = mechanism for the *mapping repository* should be adaptable, = so that the mapping information can be stored either in the = way it is now, or in the way you propose. regards. ---- Original m= essage ---- >Datum: Wed, 27 Feb 2002 07:07:28 +0100 >Von: Lasse Lindg=E5= rd <ll...@li...> = >Betreff: RE: [OJB-developers] Kill the mapping files = >An: "'ojb'" <obj...@li...> > >That i= s what Castor does. And that is pretty bloated in my = humble >opinion. = > >I thought that OJB was a pure Object-Relational framework ? > >/La= sse > >-----Original Message----- >From: objectbridge-developers-admi= n...@li... >[mailto:obj...@li...= urceforge.net] = On Behalf >Of Christian Sell >Sent: 27. februar 2002 00:43 >To: 'ojb'= >Subject: Re: [OJB-developers] Kill the mapping files > > >the mapp= ing repository storage architecture should be = abstracted such >that >providing specific mechanisms (XML, SQL, whatev= er) is a = matter of >implementing a simple interface, IMO. > >----- Original Me= ssage ----- >From: "Lasse Lindg=E5rd" <ll...@li...> >To: "'ojb'" <obj= ect...@li...> >Sent: Tuesday, February 26= , 2002 11:42 PM >Subject: [OJB-developers] Kill the mapping files > >= >> This might be a controversial suggestion. But it is an = idea I got and >I >> would like to get some feedback on it. >> >> Wo= uldn't it be possible to just drop the XML mapping files. >> >> The wa= y I see it XML files contain data. And data should = be persisted >in >> a database. The way it is now the XML files are ma= rshaled = to OJB >mapping >> objects which OJB then uses to figure out how to ma= p the = objects to >> tables. >> >> If we didn't have the mapping files it wo= uld 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. >> >> = 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 fa= ctory = pattern that >returns >> hardcoded prebuild mapping objects. >> >> O= ne might argue that the current XML files are pretty = simple to edit >in >> a text-editor. But I cannot see that it is signi= ficantly = 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. >> = >> I hope my suggestion is clear enough. >> Would this be a possible wa= y to go ? >> >> /Lasse >> >> >> ___________________________________= ____________ >> Objectbridge-developers mailing list >> Objectbridge-d= eve...@li... >> https://lists.sourceforge.net/lists/= listinfo/objectbridge- developers > > >_____________________________= __________________ >Objectbridge-developers mailing list >Objectbridge= -de...@li... >https://lists.sourceforge.net/lists/= listinfo/objectbridge- developers > > >_____________________________= __________________ >Objectbridge-developers mailing list >Objectbridge= -de...@li... >https://lists.sourceforge.net/lists/= listinfo/objectbridge- developers -- = NetMail powered by NetCologne |
|
From: <ll...@li...> - 2002-02-27 23:03:36
|
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 |
|
From: Thomas M. <tho...@ho...> - 2002-02-28 15:37:18
|
Hi again, Lasse Lindg=E5rd wrote: > Thomas, >=20 > I think your "cost-benefit" argument is a very valid one. >=20 > 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. This is a good argument. Lasse, why not give it a try and provide a little prototype showing how=20 to persist the MetaData. For the time being we can keep things simple and ignore the bootstrap=20 issues. Simply write and read a complete DescriptorRepository to/from=20 the database. A DescriptorRepository should have a uinque Name like=20 "repository-Myapp-1.2-production" >=20 > Maybe the right approach is to hope and wait for a XML > PersistenceBrooker to come along and the refactor the metadata to use > that. That would make things much easier, indeed! (Any volunteers ? ;-) ) >=20 > How about using the mapping api directly instead of using XML files. Is > that possible as OJB is constructed now ? >=20 Yes, definitely. That's what I'm always talking about. You can assemble=20 the DescriptorRepository programmatically. There is even a Method in the=20 PersistenceBroker interface to add new (or change existing)=20 ClassDescriptors to the repository. The ojb.broker.metadata.RepositoryXmlHandler (A sax document handler)=20 shows how to use the metadata API to assemble a repository. cu, Thomas |
|
From: <ll...@li...> - 2002-02-28 19:25:59
|
I maybe the XML PersistenceBrooker isn't too hard to write. Perhaps it would be possible to hook-up the "Long-term-bean-persistence" framework in jdk 1.4 with the OJB metadata interface. If not, maybe some other existing XML persistence framework might fit in. I would really like to give it a shot. I am currently under some pressure on a project deadline, so I cannot promise you anything in a near future. But I will look into it. At least with some research work. /Lasse -----Original Message----- From: obj...@li... [mailto:obj...@li...] On Behalf Of Thomas Mahler Sent: 28. februar 2002 16:37 To: Lasse Lindg=E5rd Cc: 'ojb' Subject: Re: [OJB-developers] Kill the mapping files Hi again, Lasse Lindg=E5rd wrote: > Thomas, >=20 > I think your "cost-benefit" argument is a very valid one. >=20 > 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. This is a good argument. Lasse, why not give it a try and provide a little prototype showing how=20 to persist the MetaData. For the time being we can keep things simple and ignore the bootstrap=20 issues. Simply write and read a complete DescriptorRepository to/from=20 the database. A DescriptorRepository should have a uinque Name like=20 "repository-Myapp-1.2-production" >=20 > Maybe the right approach is to hope and wait for a XML > PersistenceBrooker to come along and the refactor the metadata to use > that. That would make things much easier, indeed! (Any volunteers ? ;-) ) >=20 > How about using the mapping api directly instead of using XML files. Is > that possible as OJB is constructed now ? >=20 Yes, definitely. That's what I'm always talking about. You can assemble=20 the DescriptorRepository programmatically. There is even a Method in the PersistenceBroker interface to add new (or change existing)=20 ClassDescriptors to the repository. The ojb.broker.metadata.RepositoryXmlHandler (A sax document handler)=20 shows how to use the metadata API to assemble a repository. cu, Thomas _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X