Hi Björn, On 10/17/07, Björn Granvik <[EMAIL PROTECTED]> wrote: > 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?
Sure, it all depends on the scope and width of the solution, and the risk of having several OrderImpl called from for example a factory class. But I can agree that if there is only one solution and care is taken to create a package structure that separates different implementations, the OrderImpl solution is handy and totally ok by me. > > >> ** 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 > Thanks, To sum up the input from you and Johan, I think that if we see this guide as the "Beginners Guide to Neo", the subreference pattern described is sufficient for getting started. We should add early in the document that if the node space is large (e.g. many customers) this must be taken into consideration and we should start working on an "Advanced guide to Neo" where we explain the linked customers and node tree patterns. What do you think about this? Best Regards Klas _______________________________________________ Neo mailing list [email protected] http://lists.neo4j.org/mailman/listinfo/user
