cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <blackn...@gmail.com>
Subject Re: Cayenne Modeler Extensions
Date Mon, 16 Jan 2017 15:49:14 GMT
On Sun, Jan 8, 2017 at 2:40 AM, Andrus Adamchik <andrus@objectstyle.org>
wrote:

>
> > On Jan 8, 2017, at 1:12 AM, Michael Gentry <blacknext@gmail.com> wrote:
> > I'd forgotten I had included DB comments, but I can see the value of
> them.
> > I suppose if you are doing a sync with the DB, if there are differences,
> > query the user for which one to keep/use?
>
> Or just always override from DB (after all you want a single source of
> metadata in your stack).
>

My initial thoughts were to just include DB comments (that are in CM) in
the SQL generation feature, but this can clearly be expanded upon.


> Our use-cases never involve DB syncs, so this could be quite a blind spot
> for me.  (We maintain Flyway
> > migration scripts separately and update the Cayenne model by hand as
> > needed.)
>
> Yeah, DB-first flow wasn't feasible in 3.1. And until M3/M4 wasn't stable
> enough in 4.0 (M5 has the last few known bugs squashed). Try it now though.
> It works like a charm.
>

Still on 3.0.2 ...  :-)


> We had looked at overriding getters/setters for annotations, but we didn't
> > want to do that 1000s of times, so we gave up.
> > I see value in the
> > superclass being able to have annotations along with JavaDocs for various
> > attributes and relationships, plus the class itself.  The superclass is
> > essentially maintained outside of the IDE currently, anyway (you may look
> > at the code, but you don't edit it), so I don't think it'll be too bad.
>
> But how does this save us work creating annotations? If you had to
> override 1000's of methods, then you will have to create 1000's of
> annotations in the Modeler as well to achieve the same effect. The only way
> to cut down on the number of (repeating) annotations is if they are are all
> applied to the same properties of different entities. Then they can be
> moved to a separate interface (or a superclass common to all entities), all
> outside the Modeler and within the IDE.
>

Since you spun off a separate thread, I'll comment over there...


> I'm also viewing this as a separate XML file.  One that wouldn't need to
> be
> > deployed, although it wouldn't hurt if present.  Nothing in it is
> required
> > for runtime support, unlike the main model.  Everything is
> class-generation
> > extensions only.
>
> This definitely has merit. Lazy loading of all this metadata (i.e.
> skipping it in runtime) is a good idea. But we need to make sure this file
> is fully integrated in Cayenne project model and toolchain and can be
> loaded on-demand from anywhere, not just the Modeler.
>
> Also we need to look at the bigger picture here. We want to be able to add
> and manage extra project files for many different reasons. I have this list
> for now:
>
> 1. cgen-related metadata - this discussion.
> 2. cgen custom templates - makes sense to keep them in the project and in
> version control together with Cayenne XML files.
> 3. cdbimport filters and settings - currently this is configured inside
> the build system (pom.xml, etc.), but I'd really like to move it to the
> Cayenne project (and make it editable in the Modeler).
>
> So a generic mechanism for referencing and managing extra files with the
> project (lazy-loading, saving, etc.) is a prerequisite to implementing the
> above.
>

I was fully expecting this metadata to be available to more than CM.  It
would absolutely have to be available to cgen, for example.  I also want VM
template management to be incorporated into CM, too.  It might be overkill,
but you should be able to specify which template to use for which entity.
Most wouldn't do this, of course, but it should be doable.

mrg

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message