Hi Björn,
Thanks for the feedback, I'll comment further below.
/Klas
On 10/15/07, Björn Granvik <[EMAIL PROTECTED]> wrote:
> Hi Klas,
>
> The document you're writing is spot on! The subject really needs to be
> described. And probably discussed too :-)
> I've read some of it and you'll find some of my thoughts below in no
> particular order.
>
> ** Prefix pojo naming
> *public class NeoOrder implements Order
> I don't think anyone wants to use this naming scheme. The neo-prefix
> displays an implementation detail and moreover will make the sorted
> order (for instance Order and NeoOrder) separate the two files even
> though they are clearly linked.
> 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. It's all
about setting a naming standard and I'm not religious so your
suggestion is fine by me. :)
But I don't agree that no one will want to use my naming scheme, I
know several that prefers this way.
>
> ** Repeated iterables
> *In the chapter "Coding Relationships" there is a
>
> private static class OrderIterable extends AbstractCollection<IOrder>
>
> Should probably be parameterized using IOrder and the pojo object Order
> so that there would be no need to write a specific wrapping
> OrderIterable for each pojo.
> I do believe that there is such a utility already in the code somewhere.
> 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?
>
> ** Exposed underlying node
> *In the chapter "Adding a relationship between wrapped nodes" you have
> an example doing
> myCustomer.addOrder( order );
>
> This is fine. However, the getUnderLyingNode() is exposed using protected.
> This will help with the above code and also for testing purposes (which
> I think you don't mention), but I have a problem with it - it's exposing
> the node.
>
> One could go the other way in Customer.java:
> public void addOrder( Order order ) {
> order.addCustomerNode( this.underlyingNode );
> }
> Not pretty and it does not help in the testdriven approach. Maybe it's
> for the best as you have done it.
>
Yes I agree that it feels somewhat awkward to let other classes deal
with the underlying node, but I didn't find any other way to achieve
this. It's also used by the Neo crew in the jayway lab i think. At
least we limit the damage with protected.
Good suggestion withh the testdriven benefits, I could add that a
benefit of the solution.
> ** 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?
>
> Klas Ehnrot wrote:
> > Hi all,
> >
> > I just wanted to let you know that there is some small additions and
> > fixes to the Neo Design Guide which can be found here:
> >
> > http://wiki.neo4j.org/content/Design_Guide
> >
> > Basically I have added a section about using Lucene as search engine
> > when doing property based searching.
> >
> > I have also cleaned up the document somewhat, fixed typos etc.
> >
> > So there are still one or two topics missing but I think the best
> > thing now is to get some feedback, especially from the Neo crew so
> > that I know if I'm going in the right direction. Despite some possibly
> > missing topics, I believe the guide could be linked to now.
> >
> > Regards
> > Klas
> > _______________________________________________
> > Neo mailing list
> > [email protected]
> > http://lists.neo4j.org/mailman/listinfo/user
> >
> >
> _______________________________________________
> Neo mailing list
> [email protected]
> http://lists.neo4j.org/mailman/listinfo/user
>
_______________________________________________
Neo mailing list
[email protected]
http://lists.neo4j.org/mailman/listinfo/user
