Ah, an exciting topic! > On Jun 9, 2017, at 5:55 PM, John Huss <johnth...@gmail.com> wrote: > For my test of loading 10,000 objects from every table in my database I got > it to use about about *half the memory* of the default class (from 921 MB > down to 431 MB).
Yeah, that's certainly expected. > So one question is how we should be addressing the need that people may > have to create their own data classes. Right now I believe the recommended > path is to subclass PersistentObject, Formally - yes. But we don't have a "recommended" way from the practical standpoint. Simply because this is too complicated for the majority of users. The most prominent example of an alt Persistent implementation is ROP, but it required a bunch of other things to work beyond the object itself and ClassDescriptor. So I commend you for trying! :) > Another approach might be to ask why anyone should need to customize the > way data is stored in the objects if we can just use the best solution > possible in the first place? +1. While making it pluggable is nice (even for our own experimentation), the goal is to settle on the most efficient design and make it the default. > I can't imagine a more efficient representation that fields. True, but fields also require reflection to be accessed "from below" (by Cayenne). Other ideas include: * use Object[] for data storage (with array positions alphabetically mapped to attribute names). * use fields, but also use class generation (that you also mentioned) to create some kind of "companion" objects (adapters) for each entity, that can operate on the fields of a given Persistent object, but present a generic API to the rest of the framework. > However, fields present difficulties for the > use case where you aren't generating unique classes for your model but just > rely on the generic class. I'd keep Map-based CayenneDataObject for the 5% of apps that use generic classes. (Unless we can make Object[] based structures to work. Those are also generic). Andrus
