Hi everybody: I will comment later more.
-I am just going to keep a presentation about the topic in my university here in Finland for theorists and I am making those slides at a moment.. One social observation: In my understanding the situation has been that people (me too) have not been understood that that a modified object structure can always be returned back into the database in a deterministic and meaningful way. - I mean that the well defined result exists always for an operation. This is because the modifications in Run-Time memory can be so arbitrary. For this reason no one has been able to think the problem? Therefore the method can not have been in any db standard either. Regards, Heikki On Fri, May 20, 2016 at 7:49 PM, Tilmann Zäschke <zaesc...@gmx.de> wrote: > Hello Hei, > sorry, I posted my answer first only to the dev list, I'm not sure you are > on it. > So here it is again, with some updates: > > > Hi, > > I haven't read the whole post in detail, but I understand the main idea is > garbage collection in databases. This reminds me of similar concepts in > osome object databases, such as GemStone/Smalltalk ( > https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-ReleaseNotes-3.3/GS64-ReleaseNotes-3.3.htm). > However, I'm not aware of any major Java-ODBMS that supports it. > > Some comments: > > - As Andy describes, it could be supported via a property of the PM. > However, there may be scenarios when 'embed' and 'makePersistent' are > regularily use in the same transaction, so if the feature would be widely > used, it may make sense to have a dedicated 'embed' method. > > - as far as I am aware, the JVM has moved away from reference counting. > The situation in an DBMS may be different to an in-memory JVM, but if an > ODBMS implements GC, it may be worth checking out other garbage collection > techniques. One problem are reference cycles, I haven't read the full > blogpost how this is solved. > > - It seams that enabling garbage collection via reference counting will > have quite some impact on performance, because objects get bigger (little > impact) and because it requires updating of additional objects in the > database to update the reference counters (the counters also need updating > when _adding_ references). I would therefore argue that support for garbage > collection should be determined at database creation time, or as a flag > when defining database schema. This would allow avoiding the GC overhead > when GC is not required. > > - We would need to be able to identify root objects which should not be > garbage collected. This could also be done via a flag on the schema, i.e. > every object of a class that has no reference counters is automatically a > root object. > > Cheers, > Tilmann > > > > On 13.05.2016 15:49, Andy Jefferson wrote: >> >>> Hi, >>> >>> -I have invented a new declarative method to update object databases and >>>> I >>>> would like to introduce that method you. >>>> >>>> My question is: >>>> Should the functionality of this method included in some future >>>> versions of >>>> JDO (and perhaps some other definitions/systems under Apache)? >>>> Also I am interested about your comments/critique on the method. >>>> >>>> The name of the method is "embed" and it resembles the command >>>> pm.makePersistent(s); >>>> used in JDO-enabled applications. The embed method is called in >>>> equivalent >>>> way, >>>> db.embed(s); >>>> but it has a larger functionality than the current makePersistent >>>> method. >>>> >>> My opinion/comments, others may have other thoughts : >>> >>> For something to be part of JDO, it needs to be widely applicable across >>> other datastores, not just for one "type" of datastore. If it is only >>> implementable on 1 type of datastore then standardising it would be >>> "premature"; that isn't to say that it isn't applicable to others. >>> >>> From what I read of your method it is basically a makePersistent >>> (attach) but with "deleteOrphans" enabled; i.e it addresses the object >>> graph defined by the input object, and additionally deletes orphaned >>> objects. Firstly it is entirely reasonable to be able to do that right now >>> in terms of API (**assuming the JDO implementation provided the >>> internals**) since the user can call pm.makePersistent and can have set >>> properties on the PersistenceManager just before that call >>> (pm.setProperty(...), so can set some "deleteOrphans" flag). From that I >>> can conclude that I don't think there would be any change to the API needed >>> to provide your mode of operation. >>> >>> Deleting orphans may vary dependent on the precise relation, hence why >>> JDO allows metadata on each field, so some orphans can be deleted and >>> others not. >>> >>> Clearly a JDO implementation would need to provide a "deleteOrphans" >>> mode internally to support this. >>> >>> Detail of how your method works in an object database, whilst >>> interesting, is not of relevance to the JDO spec question, since the spec >>> doesn't define HOW an implementation implements features >>> >>> >>> Regards >>> >> >> >
