RE: Re: AW: [Objectbridge-jdo-dev] jdo extension
Brought to you by:
thma
Menu
▾
▴
RE: Re: AW: [Objectbridge-jdo-dev] jdo extension
|
From: Andy L. <aj...@as...> - 2002-05-24 18:14:32
|
and missed again.... > I think that works. > >> How does this sound for starters anyways: >> >> JDO Extensions >> >> Set the referenced table using table-name as an extension of the >> class. >> >> <class name="Product" identity-type="application"> >> <extension vendor-name="ojb" table-name="Product"/> >> >> Set the referenced column in the above table using column-name and >> optionally a jdbc-type. jdbc-type matches the ojb type mapping. >> >> <field name="stock"> >> <extension vendor-name="ojb" column-name="stock" jdbc-type="INTEGER"/> >> </field> >> >> If no extensions are specified then the following default mappings >> will occur: >> >> table-name=Class.getName() >> >> column-name=field name >> >> jdbc-type=equivalent java type >> >> >> >> Travis >> >> ---- Original Message ---- >> From: Christian Sell <nc-...@ne...> >> Sent: 2002-05-24 >> To: obj...@so... >> Subject: Re: AW: [Objectbridge-jdo-dev] jdo extension >> >> >> >> ---- Original message ---- >>>Having enough defaults so that a pure stnadard .jdo file >> will handle the >>>most obvious cases is a huge step forward in usability, ease >> of use, and >>>reducing learning curve. >>> >>>I think htis should be a major objective actually. Not only >> does it make it >>>easier to work with, but I have found that easeo of use >> ascpects like this >>>tend to force cleaner architectures as well. >>> >> >> I disagree. A database is a resource that must not be taken >> lightly, as it has the strongest performance implications if >> treated wrongly. Luring people into the illusion that they >> can do away with it by the push of a button has the potential >> of generating disappointments. >> IMO, a good O/R framework must either exploit or allow easy >> access to the full capabilities of the underlying DBMS. And >> in a corporate production scenario, you will almost always >> have to map your objects to a pre-existing schema. >> >> I see a value in generating default mappings as a starting >> point for projects that have the privilege of starting from >> scratch, however. >> >> regards, >> Christian > > I agree it should not be taken lightly. However anytime the tools can > make a reasonable asumption, it should. That should in no way limit the > ability to manually adjust and set every existing option for tuning or > specific usages. > > The problem with generating default mapping and then cusomtizing them > by hand is that it does not provide a good maintenenance cycle when the > model changes. Do you regenerate, and recusomtize? Or make all the > changes manually? > > A mapping specification that only includes overrides to known defaults > on the other hand allows you to only deal with new or changes variances > from the defaults. I am also a fan of tools to go between object model, > mapping file, and database, and being able to starting with any of the > three and produce at least a starting point for either of the other > two. > > >> >> _______________________________________________________________ >> >> Don't miss the 2002 Sprint PCS Application Developer's Conference >> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm >> >> _______________________________________________ >> Objectbridge-jdo-dev mailing list >> Obj...@li... >> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev >> >> >> >> _______________________________________________________________ >> >> Don't miss the 2002 Sprint PCS Application Developer's Conference >> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm >> >> _______________________________________________ >> Objectbridge-jdo-dev mailing list >> Obj...@li... >> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > "The heights of genius are only measurable by the depths of stupidity." "The heights of genius are only measurable by the depths of stupidity." |
