I'll try to ignore the blatent trolls. But you want things easier to
do in Objectify than Twig, so here's a few:
-----
How, in Twig, do you rename a field?
Objectify lets you import data from a variety of historical formats;
as you load and save data it will naturally be transformed in format:
class Person {
@Id Long id;
int age;
@AlsoLoad("name") String fullName;
}
Now, assume that the user has queries like:
Query<Person> q = ofy.query(Person.class).filter("age >", 65);
Does this query still work in your system? If so: After a few
renames, how many queries will you be running? Can you do batch gets
on their ids? I mean, after you implement batch gets, of course.
Versions are an ugly solution to this problem and they make a giant
mess out of the datastore.
-----
How, in Twig, do you retire an Enum value?
class Car {
@Id Long id;
int year;
Color color;
public void migrateColor(@AlsoLoad("color") value) {
if ("AQUA".equals(value))
color = Color.BLUE;
else
color = Color.valueOf(value);
}
}
-----
How, in Twig, do you make an entity cached? If it's in your docs, it
is not easy to find. The Objectify version:
@Cached(expirationSeconds=600) // optional expiration
class Person {
...
}
-----
How, in Twig, do you load a variety of different objects in parallel?
Map<Key<Object>, Object> result = ofy.get(
new Key<Car>(Car.class, carId),
new Key<Person>(Person.class, personId),
new Key<Plant>(Plant.class, plantId));
-----
> Usability, performance and maintainability are the strengths of Twig I
> would prefer to focus on.
All I seem to see you focusing on is OR, the bizarre notion that
"addFilter()" is somehow more maintainable than "filter()", and an
even stranger notion that someone will be confused by iterable
queries.
I don't want to knock the OR feature, but it's hardly the must-have
feature you make it out to be. In the GAE issues list, OR support
doesn't even make the first two pages, ranking it somewhere below
Erlang and TCL support. I couldn't even find an issue for it.
Obviously there are a *lot* of people building applications on GAE
without OR in the framework, and they don't seem to be complaining too
loudly about it.
Maybe you're right, and we'll see a giant land rush for OR support.
Except that Twig has supported OR queries for quite some time, and it
still hasn't been getting traction.
You might very well have something with parallel queries. As with all
asynchronous code, they come at a cost of maintainability, but for
some - maybe even many - applications, parallel queries could be a
game changer. Rest assured, we will be watching.
> I don't deny that the developer could hit an initialized object. But given
> that they have to explicitly turn on this feature I think you are
> over-stating the danger. The advantages are huge - POJOs and cleaner code.
I'm simply offering you the lessons that others have learned
developing a highly analogous feature (proxies) in Hibernate. It
isn't that proxies aren't useful, it's that they get screwed up a lot.
As someone that has done a lot of work with Hibernate proxies, I can
tell you firsthand that they can be very difficult to get right in a
complicated schema. And "hollow" entities which nominally work but
return invalid data will be worse.
Again, it is not my intention to say this feature is inherently wrong
or bad - but that it's not the great revolution that you make it out
to be. It comes with a cost which the Objectify developers are not
currently willing to pay.
>> Yep. Objectify entities are plain, boring POJOs that work just like
>> every other Java object. You can load them, clone them, save them,
>> serialize them in and out, whatever. There is no magic.
>
> I would hardly call an object with such restrictions a POJO.
You seem to have an odd definition of Plain Old Java Object. POJOs
can be copied, created, cloned, whatever. You can have two of them in
memory with the same id.
This is actually pretty core to the philosophy of Objectify: We hate
magic. We're pretty resistant to features that are not transparent,
and when we do implement features that are magical (like @Embedded),
we document the hell out of it.
Hollow, stateful entities with lifecycles are pretty magical.
Cascading loads and saves are pretty magical. POJOs and Keys are
simple.
> My real world application is not possible with Objectify!! It uses OR
> queries executed in parallel.
> [...much other conversation...]
> OR's are essential - batch gets are a trivial feature that will be added
> with the load command.
Essential? So all those applications deployed on GAE right now
(including mine) don't exist?
Jeff
--
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.
