I guess my issue with "context" is it is kind of nebulous in software -- everything has a context and putting it in a class name, at least to me, doesn't really add value, just extra typing, but there could be some exceptions I suppose. The ObjectContext is a relational database graph manager providing CRUD operations for Java objects with lazy loading and optimistic locking... Yeah, hard to boil that down into a small succinct name.
On Wed, Nov 22, 2023 at 8:00 AM Andrus Adamchik <aadamc...@gmail.com> wrote: > Let's discuss what we can improve, and then see the impact. > > FWIW, we have both DataObject and Persistent. "Persistent" seems ok, and > we can get rid of DataObject. > > ObjectContext is a "context" :) (i.e. an isolated scope). > PersistentContext maybe? > > Andrus > > > > On Nov 22, 2023, at 8:46 AM, Michael Gentry <blackn...@gmail.com> wrote: > > > > In that case, I'd like to throw out my nomination for a class/name > change... > > > > ObjectContext (and I guess BaseContext) > > > > The words "object" and "context" don't really provide a new user or > someone > > maintaining an app with any idea what they do. I guess I'd also add > "data" > > to that list (such as in DataObject -- what exactly is this?). The word > > "base" is a bit better since it seems to imply the top-level "context" > > (whatever that is). I know when I was teaching new developers on Cayenne > > projects this naming kind of caused their eyes to glaze over for a bit. > I'd > > mainly have to wavy-hands them and tell them "just remember you need an > > ObjectContext to..." > > > > Before spitballing new names, what are thoughts/feelings on this? Yes, it > > would be a lot of global search/replace, but probably not too much effort > > outside of that. (Use a shell script to automate that task in the code > and > > docs, but the docs might need a bit more polishing.) > > > > Thanks > > mrg > > > > > > On Wed, Nov 22, 2023 at 7:18 AM Andrus Adamchik <aadamc...@gmail.com> > wrote: > > > >> I think there's going to be quite a few. Since we got rid of ROP, we can > >> tighten our naming everywhere - modules, packages, classes. > >> > >> Andrus > >> > >> > >> > >>> On Nov 22, 2023, at 8:07 AM, Michael Gentry <blackn...@gmail.com> > wrote: > >>> > >>> Hi Nikita! > >>> > >>> Both sound very reasonable to me, so +1 for that. > >>> > >>> Will there be any backward-compatibility breaking changes in 5.x? > >>> > >>> Thanks, > >>> mrg > >>> > >>> > >>> On Tue, Nov 21, 2023 at 3:04 AM Nikita Timofeev < > >> ntimof...@objectstyle.com> > >>> wrote: > >>> > >>>> Hi all, > >>>> > >>>> Wanted to share a couple of my thoughts about changes that could be > good > >>>> for Cayenne. And the first milestone release of Cayenne 5.0 could be a > >>>> perfect target for these changes. > >>>> > >>>> 1. Get rid of the `server` part in the names everywhere, starting by > >>>> renaming our core dependency from `cayenne-server` to just `cayenne`. > >>>> As we already removed the `client` counterpart, `server` just doesn't > >> make > >>>> sense anymore. > >>>> > >>>> 2. Change of the versioning schema we use for the development cycle. A > >>>> short version of the proposal: drop BETA versions, keep the version of > >>>> snapshot build always the same, and slightly change format to > articulate > >>>> what is the actual version. > >>>> > >>>> Format would look like `MAJOR.MINOR-QUALIFIER`. Where the qualifier is > >> one > >>>> of `SNAPSHOT`, `M` for the milestone or `RC` for the release > candidate. > >>>> > >>>> Example for the 5.0: > >>>> - snapshot always stays as 5.0-SNAPSHOT > >>>> - milestones releases are 5.0-M1, 5.0-M2 etc. > >>>> - release candidates are 5.0-RC1, 5.0-RC2, etc. > >>>> - and final release is just 5.0 > >>>> > >>>> And here's a reason for that change. It solves two minor problems with > >> the > >>>> current schema. The first one is that all systems think that `B` goes > >>>> before `M`, so our beta versions always look older than milestones. We > >> are > >>>> not that strict about what is beta nor are we enforcing any rules, so > >> there > >>>> should be no problems with that. > >>>> The second one is that projects using SNAPSHOT versions should update > >>>> dependency every time we make a dev release. Again not a big change > and > >>>> should not affect anything really, as there shouldn't be many projects > >>>> brave enough to just use SNAPSHOT. > >>>> > >>>> Note this change does not affect overall versioning, e.g. patch > versions > >>>> like 5.0.1 or global updates like 5.1. > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Nikita Timofeev > >>>> > >> > >> > >
