Hi Klas,
** Prefix pojo naming
I would go for:
OrderImpl --> Order
This is an interesting topic and often debated within projects. I have
heard arguments from both sides and they are both valid imo.
Since all callers will only use the Order Interface and never actually
use the NeoOrder/OrderImpl it won't affect the calling code.
True, the implementation will be sort of hidden.
It will still, though, mean disparate classes. In a busy package that
would seperate the files.
But I don't agree that no one will want to use my naming scheme, I
know several that prefers this way.
Do they prefix and do "MySQLOrder" if that is their persistence solution?
** Repeated iterables
The Neo crew should be able to help on this. Anyone?
Yes some sort of utility class in Neo would be great if it is possible?
Neo gang, where is the class?
** Meta model
*"Organizing your Nodespace" and subreferences pattern. This looks like
a poor man's meta model. I've lobbied for a proper meta model support in
Neo since there are many things one could do with a such a concept.
This example could drive for home-grown solution where a standard
support in Neo itself would to the trick for me.
The pattern in itself looks fine, apart from scaling, I guess. A couple
of millions of customers might not be too fun. Does anyone have
experience with scaling this pattern?
Yes this is the subreference node discussion we had a while back and I
too think that a proper metamodel implementation in Neo would be great
and would then replace this pattern alltogether. I think Emil
mentioning something about that?
A meta solution is on the discussion boar, if I understand things correctly.
However, your pattern still stands even if there is a standard meta model.
The subreference pattern, and probably several more, are needed as
design patterns in Neo, since these replace tables as a construction
metaphor in SQL.
For instance a constructing the following in Neo is different as in SQL:
Customer --* Order --* Item
Moreover, suppose we have millions of customers in a micro payment
scheme or just the one Big Customer. These cases would be different in Neo.
The sub reference pattern and others (b-tree, and what not) will be
sorely needed.
So I would just add a sentence about it being a general approach (and
not necessarily "only" a meta approach).
Even more, perhaps a chapter on meta structures in Neo (not the same as
meta model) would be nice in the future :-)
Cheers and keep up the good work - your document is needed,
Björn
_______________________________________________
Neo mailing list
[email protected]
http://lists.neo4j.org/mailman/listinfo/user
