| Author |
Message |
|
|
Post subject: Standard for defining O/R mapping in UML?
 Posted: Mar 17, 2004 - 12:37 PM
|
|
|
|
Are there any standards for defining an O/R mapping in UML. I know I can specify the object model in UML, but what about the mapping between the objects and the datastore - is that always proprietary/tools specific?
If I put the mapping information in a runtime config file, how do I keep it in sync with my object model?
Any ideas  ? |
|
|
| |
|
|
|
 |
|
|
|
Post subject:
Posted: Mar 18, 2004 - 11:42 AM
|
|
|
|
| You might try checking the OMG site www.omg.org. They are responsible for the uml standard. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 18, 2004 - 08:29 PM
|
|
|
|
|
|
|
|
|
|
|
Post subject: UML and Datamodeling
Posted: Mar 20, 2004 - 05:06 AM
|
|
|
|
EclipseDatabse is trying to find a solution to Datamodeling and it is not easy.
We dediced to consider both MDA and UML/object approach, using JDBC or JDO. We have implemented bottom up approach to reverse existing database and then generate code using Torque, Hybernate others... mappings.
We are implementing UML JDO profiles using MDA approach. Data is a stereotype and infortmation are saved in XMI.
I personaly like JDO technology, but many projects needs JDBC.
Finaly we are working on a kind of JDO/JDBC integration (no, it is not stupid idea !!). Reversing existing database, modeling, and using JDO to generate code. Easy and efficient databases migrations.
We do not have the magic trick, therefore Omondo will implement Torque, Htybernate and other mappings . We will use JDO and datamodeling having a MDA approach based on EclipseUML2 (XMI 2.0).
Hopes it help !!!
Blade, |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2004 - 12:05 PM
|
|
|
|
| Isn't JDO more for OODB mapping? Is there any standard that doesn't force me to use J2EE and that is more suited to RDB? |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2004 - 01:15 PM
|
|
|
|
|
|
|
|
|
|
|
Post subject: JDO
Posted: Mar 23, 2004 - 03:23 AM
|
|
|
|
EclipseUML is currently adding a JDO UML profiles using EclipseJDO plugin + Kodo.
EclipseUML will allow any specific JDO vendors to add its own JDO profiles and XJDO, Libelis and others ... are welcome.
Blade, |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 25, 2004 - 12:22 PM
|
|
|
|
| Do any of these approaches offer integrated OR mapping and caching? Is caching something I can specify in my design/configuration or do I integrate it afterwards? |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Apr 06, 2004 - 06:00 PM
|
|
Joined: Feb 03, 2004
Posts: 5
|
|
|
|
|
|
|
|
|
Post subject: JDO is mostly used with relational databases!
Posted: Aug 05, 2004 - 06:35 PM
|
|
|
|
| Anonymous wrote: | | Isn't JDO more for OODB mapping? Is there any standard that doesn't force me to use J2EE and that is more suited to RDB? |
Most of the JDO implementations are for relational databases. The beauty of JDO is that is supports relational, object, and pretty much any other persistent technology that you care to use, without a code change to your objects.
I highly recommend a visit to http://www.jdocentral.com, or google JDO to get a better feel for it. JDO 2.0 introduces several new capabilities, including standardized O/R mappings, direct exposure of the underlying datastore connection (JDBC Connection for relational implementations), customized fetch groups, named queries, and more. JDO 2.0 addresses easily 98% of the concerns that I've ever heard mentioned.
If you look at the newly proposed EJB 3.0 entity beans in the EJB 3.0 early draft specification, you'll see how similar they are to JDO-persisted objects: POJOs. The difference between EJB 3.0 EBs and JDO is that EJB 3.0 EBs require a container; JDO does not. You can imagine how that makes vendors like BEA & IBM worried -- all of the sudden, their container is irrelevant. Additionally, both technologies do a reasonable job of commoditizing the underlying datastore, but again, another difference between EJB 3.0 EBs and JDO is that EJB 3.0 EBs are, according to the specification, restricted to relational databases. That means different APIs for EJB-based developers depending on which environment they're targeting (EJB v. non-EJB). Since JDO can be used outside and EJB container or inside an EJB container (including transaction integration), the choice should be pretty clear.
Hope this helps.
Hope this helps. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Aug 05, 2004 - 06:58 PM
|
|
|
|
|
|
|
|
|
|
Log in to check your private messages
Go to Administration Panel
