Thanks for verifying that Koen. I'll run the changes (if any) to the
domain model mapping classes (PersistentClass, Component, etc) from
o.h.mapping after I get to them before we finalize anything.
On Mon, Oct 26, 2015 at 3:12 PM Koen Aers wrote:
> Hey Steve,
>
> The changes that you describe b
Hey Steve,
The changes that you describe below will have almost no impact on the tooling.
It requires the removal of IColumn.getValue() but AFAICS this functionality is
only used twice and I am even not sure if it should be used where it is used. I
am pretty sure there is an easy way to deal wi
Hey Steve,
The changes that you describe below will have almost no impact on the tooling.
It requires the removal of IColumn.getValue() but AFAICS this functionality is
only used twice and I am even not sure if it should be used where it is used. I
am pretty sure there is an easy way to deal wi
So here are the general proposals per object:
1) Column - The main change proposed is to distinguish between the logical
name and physical name of a Column, so I propose that we keep both on the
Column for easier access. I also propose that we remove Value from being
stored on Column; it is an aw
Really its a question about planning. The current model is very limiting
in many respects. We have been planning on whole-sale replacing it for
some time. This is a proposal to limit the breadth of the changes to just
the relational model to extend the lifetime of the rest of the model (I
assume
Hey Steve,
Changing the mapping model as you propose will definitely have impact on the
tooling code. Concepts like Table, Column and ForeignKey are present in the SPI
that was devised to isolate the Hibernate runtime code from the Eclipse tools.
However, this layer is not cast in stone and it
Koen, any thoughts on the "mapping model" proposal? FWIW, silence on this
list is taken by me to mean implicit agreement for me to do whatever I want
;)
On Wed, Oct 21, 2015 at 8:04 AM Steve Ebersole wrote:
> Getting some proposals that have been rolling around in my head down on
> paper (ele
Getting some proposals that have been rolling around in my head down on
paper (electronically speaking)..
*Caching SessionFactory state*
The Jira[1] contains the details. The basic gist is to allow for slimming
down the in-memory size of the SessionFactory based on how we store certain
SF-scope
