Hi Corneliu!
About mapping different classes to the same table, this worked for me
in the dev server:
@PersistenceCapable(identityType = IdentityType.APPLICATION,
table="mappedTable")
public class Mapped1 {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;
String valueInCommon;
String value1;
// ... getters-setters
}
@PersistenceCapable(identityType = IdentityType.APPLICATION,
table="mappedTable")
public class Mapped2 {
@PrimaryKey
@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Long id;
String valueInCommon;
String value2;
// ... getters-setters
}
@Test
public void testMultiMapping() throws Exception {
PersistenceManager pm = pmf.getPersistenceManager();
Mapped1 m1 = null;
Mapped2 m2 = null;
pm.currentTransaction().begin();
m1 = new Mapped1();
m1.setValueInCommon("m1valueincommon");
m1.setValue1("m1value1");
pm.makePersistent(m1);
pm.currentTransaction().commit();
pm.currentTransaction().begin();
m2 = pm.getObjectById(Mapped2.class, m1.getId());
Assert.assertEquals("m1valueincommon", m2.getValueInCommon());
Assert.assertNull(m2.getValue2());
pm.currentTransaction().commit();
}
The thing is that you can specify the name of the target table in the
@PersistenceCapable annotation. It can be independent of the classes,
they do not need to be in separate packages. This way if you really
want to you can create entities in the same table using JDO, some of
them having a particular attribute while others not.
Marton
On Sep 21, 9:20 pm, Corneliu Paul Lupulet <[email protected]>
wrote:
> Thank you very much for your feedback Marton :)
> I hope you don't mind, but i will write some further comments to sustain my
> cause.
>
> I also would like to hear the opinion of someone from Google. I know you
> guys recommend JDO, but can you give me some arguments against using the low
> level API, besides portability (i plan to stick to google datastore
> services) or code complexity. Why not harness the full power and flexibility
> that the datastore has to offer ?!
>
>
>
> On Mon, Sep 21, 2009 at 6:35 PM, Marton Papp <[email protected]> wrote:
>
> > Hi Corneliu!
>
> > I also had doubts about using JDO in GAE when I started to work with
> > it. Especially because I met several bugs and it was annoying and time
> > wasting to figure out what was going wrong. But then the bugs were
> > fixed in the next release, so I think the guys are generally doing a
> > good job.
>
> > About the limitation with the non-existing property, you are right. It
> > seems to me that JDO will create a property with a null value once you
> > declare and map it. Do you have a real-life scenario where this
> > limitation is an issue that you cannot overcome with the features
> > provided by JDO? I think if you really need to have some entities
> > having some properties, and others not, and still use JDO, then you
> > could try to *map different classes to the same database entity*, with
> > different properties defined in the classes. I have never tried that
> > though, so I am not sure if it would work, and definitely would not be
> > convenient.
>
> How would i map different classes to the same database entity? They need to
> have the same name. What do i do? I put them in different packages? On the
> other hand, if i have an older version and a newer version of the same
> object (with an extra field let's say) and i want to update a common field
> on all objects (both old and new), i can do it with a couple of lines of
> code using the low level API.
>
> Again i would like the opinion of someone from Google. Why "hide" this
> wonderful feature (dynamic schema - different properties of objects of the
> same kind) while using JDO.
>
>
>
> > About mapping collections with many entities inside, I think I just
> > wouldn't do it. If the collection is too big to be effectively loaded
> > into memory, then you are right to be using queries instead. In this
> > case you should not map it as a collection, but handle the parent-
> > child relationship explicitly. But still, collection mapping can be a
> > convenient option if you have only a small number of entities in your
> > collection. This does not make JDO less flexible, on the contrary, it
> > introduces an extra service.
>
> > Your idea about processing just part of the results at once in a query
> > seems to be okay. I think a similar approach is described to handle
> > pagination of large result sets somewhere in the forums.
>
> > As for me, I would not recommend you to create your own data access
> > layer using the low level API unless you really need it or you really
> > do not need any of the features that JDO provides. It still provides
> > some convenient features that you would have to live without or
> > reimplement if you decide not to use JDO (starting with mapping java
> > classes to persistent storage, which I think is a good thing). Most of
> > the problems you mentioned are not solved by using the low level API
> > anyway, so if you want to create some classes that make data access
> > easier for you applications then you can build them on top of JDO as
> > well, without any major drawbacks.
>
> > And as final reason why to use JDO, these guys who wrote the docs
> > recommended to do so, and they must have some reason to say that. :)
>
> > Marton
>
> --
> Corneliu Paul Lupulet
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en
-~----------~----~----~----~------~----~------~--~---
