On 3/5/12 18:28 , Niclas Hedhman wrote:
Good Stuff as usual...
In other words, what exists in memory is a REPRESENTATION of the "object",
rather than "The Object" proper. Like in REST, you can never see the object
"as it is", only through views. I kinda like this, conceptually, and if we
could support this in Qi4j explicitly, it'd be awesome.
Can we do that? I don't know!
We have not been afraid to set the bar high before, so why stop now.
Doesn't it "only" boils down to additional Entity Store SPI
information dividing up the data chunks across roles? If I store a
"Person" and then retrieve an "Employee", only the overlapping data
(same Method accessor type) will be part of the Employee of the same
UUID, which can then be populated with yet additional information,
without destroying the Person content that wasn't loaded. I.e.
namespace separation but with namespace inheritance.
So, if I create a Person (which may have several stateful mixins), and
assuming that that usecase does not know about Employee types or data,
and then proceed to try and load it as an Employee, the mixins specific
for Employee will be empty. And how will it know that I can indeed load
it as an Employee? It seems to me that the developer would have to
explicitly "add" the Employee type before being able to load it as an
Employee.
This creates a lifecycle that is something like:
1) Create instance with Person type
2) Use instance with Person type
3) Use instance with Person type, and explicitly add Employee type
4) Use instance with Employee type (this requires that Person type is
not visible from the application codes point of view, or else SPI cannot
know which type to use)
5) Delete instance
What I'm having a really hard time seeing is how the SPI will know which
type to use when loading. If we assume a many application - single
database setup it becomes trivial though, as the app using Employee will
be distinct from the Person creating app.
Argh... brain hurts..
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
