HELP! Ebean shows non deterministic behavior

[PlayDeveloper]

Hi,

today we have a strange behavior with ebean and Junit-Tests. We start
the tests from Eclipse with VM-Argument
"-javaagent:${container_loc:/my-proj}\my-proj\lib\ebean-2.7.3-
agent.jar=debug=2"

Sometimes fields are null, which are not-nullable, so in the database
they are definitely filled. This happens today 5 times at different
code-places, no run works. This is really annoying and which is a
bigger problem for me, I don't know if I can trust ebean? Can this
happens in production? It seems to be a problem with lazy-loading
which seems to failed.

Would be great to get some feedback.

Niels

[Rob Bygrave]

Do you have a test case?

>> 

Sometimes fields are null, which are not-nullable, so in the database they are definitely filled

<<

This doesn't make sense to me, you will have to explain that again.

[PlayDeveloper]

Unfortunately we have at the moment the problem only at a test in
production-code, which is closed-source, so I can't send you and
example.

Take the following example
Following Tables
Order -> Customer -> Address

In Customer you have a name which is not nullable. And Customer must
have an Address. Address has a City which is not nullable.

Now you read all Orders without join. Then I iterate over all Orders,
for each Order iterate over all Customers and for each Customer over
all Address. Then check that getCity() != null. In our code we do this
over 10000 entries and sometimes we the City is null, sometimes the
name of the Customer. If you only have a few records this happens very
rarely, but if you have a lot it always break sometimes.

At the moment we use at workaround to read all data with a join-
select.

I hope this makes the problem clear.

Niels

On 11 Okt., 10:43, Rob Bygrave <robin.bygr...@gmail.com> wrote:
> Do you have a test case?
>
>
>
> Sometimes fields are null, which are not-nullable, so in the database they
> are definitely filled
> <<
>
> This doesn't make sense to me, you will have to explain that again.
>

[Rob Bygrave]

Yup, that is reasonably clear ... but my time is precious so hopefully you create a test case because that is always the first step.

No, I have not heard of such behavior.

Cheers, Rob.

[Durchholz, Joachim]

> Take the following example
> Following Tables
> Order -> Customer -> Address
>
> In Customer you have a name which is not nullable. And Customer must have an Address. Address has a City which is not nullable.
>
> Now you read all Orders without join. Then I iterate over all Orders, for each Order iterate over all Customers and for each Customer over all Address. Then check that getCity() != null. In our code we do this over 10000 entries and sometimes we the City is null, sometimes the name of the Customer. If you only have a few records this happens very rarely, but if you have a lot it always break sometimes.

This sounds like a threading issue.

The first task would be to isolate which software layer actually gets the data wrong:
- The database (you may be having dirty reads, check the isolation level).
- The connection pooling library in use, if any.
- The record caching library in use, if any.
- Ebean.
- Any software layer you built on top of Ebean.
- The unit testing code itself.

Fortunately, invalid data is easy to identify as such (nulls in specific record fields), so it should be relatively easy to probe each layer via a conditional breakpoint. If the bug goes away as you add checking, the bug is timing-related and your breakpoint checking took too long - make sure each code path hits at most one breakpoint per record (that probably means checking just one layer per test) and try optimizing the condition checking (avoid String.equals if possible, for example).

HTH
Jo

[PlayDeveloper]

OK, if you never heard from such a problem, we will try to create an
test-case.

Niels

On 11 Okt., 12:18, Rob Bygrave <robin.bygr...@gmail.com> wrote:
> Yup, that is reasonably clear ... but my time is precious so hopefully you
> create a test case because that is always the first step.
>
> No, I have not heard of such behavior.
>
> Cheers, Rob.
>

[PlayDeveloper]

Hi

On 11 Okt., 12:51, "Durchholz, Joachim" <Joachim.Durchh...@hennig-

fahrzeugteile.de> wrote:
> > Take the following example
> > Following Tables
> > Order -> Customer -> Address
>
> > In Customer you have a name which is not nullable. And Customer must have an Address. Address has a City which is not nullable.
>
> > Now you read all Orders without join. Then I iterate over all Orders, for each Order iterate over all Customers and for each Customer over all Address. Then check that getCity() != null. In our code we do this over 10000 entries and >> sometimes we the City is null, sometimes the name of the Customer. If you only have a few records this happens very rarely, but if you have a lot it always break sometimes.
>
> This sounds like a threading issue.

Mhh. we don't open any Threads and I assume that Ebean doesn't do it
too, except in findFutureList().

> The first task would be to isolate which software layer actually gets the data wrong:
> - The database (you may be having dirty reads, check the isolation level).

During tests on the tables which we read there are no writes. On the
database is only 1 Connection from the test, so I think this can be
excluded.

> - The connection pooling library in use, if any.

We use only the pool from Ebean.

> - The record caching library in use, if any.

No except Ebean cache something.

> - Ebean.
I assume here is the problem

> - Any software layer you built on top of Ebean.

No layer on top of Ebean. Ebean has a nice interface :-)

> - The unit testing code itself.

>
> Fortunately, invalid data is easy to identify as such (nulls in specific record fields), so it should be relatively easy to probe each layer via a conditional breakpoint. If the bug goes away as you add checking, the bug is timing-related and your breakpoint checking took too long - make sure each code path hits at most one breakpoint per record (that probably means checking just one layer per test) and try optimizing the condition checking (avoid String.equals if possible, for example).

In this case it's only happens if we have a lot of data and the error
doesn't happens always at the same place, so I think its difficult to
analyze with a debugger.

Thanks for your suggestions. I hope we can create an example, which
shows the behavior.

Niels

[Durchholz, Joachim]

> In this case it's only happens if we have a lot of data and the error doesn't happens always at the same place, so I think its difficult to analyze with a debugger.

Well, single-stepping to reproduce the problem obviously won't work, but conditional breakpoints can be used to narrow down the source of bad data.
If you haven't done this yet and want advice, I will provide it.

> Thanks for your suggestions. I hope we can create an example, which shows the behavior.

If the goal is to make the problem reproducible on somebody else's system, you risk ending with something that doesn't reproduce after all and having wasted a lot of work.
Narrowing down the source of nulls will enable others to step in and help; right now, everybody has to wait until you're done, with no guarantee of progress at all.

Regards,
Jo

[PlayDeveloper]

Additional Info: I made a test where I enhanced the code via ant and
it's the same behavior. So it's not an eclipse problem.
Niels

[PlayDeveloper]

Hi,

On 11 Okt., 15:46, "Durchholz, Joachim" <Joachim.Durchh...@hennig-

fahrzeugteile.de> wrote:
> > In this case it's only happens if we have a lot of data and the error doesn't happens always at the same place, so I think its difficult to analyze with a debugger.
>
> Well, single-stepping to reproduce the problem obviously won't work, but conditional breakpoints can be used to narrow down the source of bad data.
> If you haven't done this yet and want advice, I will provide it.

The problem is that you can't go back in a debugger. You can only see
the result, which we have done. I can be sure that it's a problem of
lazy loading, because if we change the query so that we have an Eager-
Fetching, it works perfectly.

>
> > Thanks for your suggestions. I hope we can create an example, which shows the behavior.
>
> If the goal is to make the problem reproducible on somebody else's system, you risk ending with something that doesn't reproduce after all and having wasted a lot of work.
> Narrowing down the source of nulls will enable others to step in and help; right now, everybody has to wait until you're done, with no guarantee of progress at all.

It's happens on two computers at out company, so it doesn't seems
computer specific and I don't know how to give more information
without send you out code. So yes you are right the way with an
example takes time. Fortunately we have a workaround so I try to
change the topic and remove the Help!. At the moment we must
concentrate to rebuild and aggregation-job ASAP. If we have finished,
we can develop an example which shows the problem. In the mean time
you must wait.

Thanks for your quick support and sorry that I can't deliver quickly
an example.

Niels

[edge]

hi Neils,

here just a few suggestions:

It sounds like a problem that we previously had (and I though we
fixed) - namely, we use weak references in the persistence context and
as far as I can remember the objects were being GC'ed and then missing
during the lazy loading resulting in properties being null.

So this is very tricky to track down - I think since you are using
Ebean a lot you should pull the code from SVN and compile locally and
then you could probably "doctor" the persistence cache to see if the
problem goes away. You probably won't easily be able to create a test
case to reproduce this - real apps are much more complex than test
cases and once you know what the problem is then the test case becomes
obvious :)

Anyway, I think that's the only way to really narrow down the suspects

Eddie

[PlayDeveloper]

Hi,

On 12 Okt., 10:56, edge <e.mcgr...@imilia.com> wrote:
> hi Neils,
>
> here just a few suggestions:
>
> It sounds like a problem that we previously had (and I though we
> fixed) - namely, we use weak references in the persistence context and
> as far as I can remember the objects were being GC'ed and then missing
> during the lazy loading resulting in properties being null.
>
> So this is very tricky to track down - I think since you are using
> Ebean a lot you should pull the code from SVN and compile locally and
> then you could probably "doctor" the persistence cache to see if the
> problem goes away. You probably won't easily be able to create a test
> case to reproduce this - real apps are much more complex than test
> cases and once you know what the problem is then the test case becomes
> obvious :)

If I understand you right, than you say that it probably fixed in the
head of SVN?

I assume that it is a problem of WeakReferences. Today we get a
java.lang.RuntimeException: Nothing in batch?
at
com.avaje.ebeaninternal.server.core.DefaultBeanLoader.loadBean(DefaultBeanLoader.java:
299)
at
com.avaje.ebeaninternal.server.core.DefaultServer.loadBean(DefaultServer.java:
526)
at
com.avaje.ebeaninternal.server.loadcontext.DLoadBeanContext.loadBean(DLoadBeanContext.java:
143)
at
com.avaje.ebean.bean.EntityBeanIntercept.loadBean(EntityBeanIntercept.java:
548)
at
com.avaje.ebean.bean.EntityBeanIntercept.preGetter(EntityBeanIntercept.java:
636)
at model.AttributeValue._ebean_get_name(AttributeValue.java:4)
at model.AttributeValue.getName(AttributeValue.java:42)
at
de.ppi.pps.wdc.aggregation.UnionAllAttributeValuesAggregator.aggregate(UnionAllAttributeValuesAggregator.java:
33)

which definitely is an problem of WeakReference. We could fix it by
increase the max-memory. It looks that Ebean use WeakReferences very
often (I found 26 References). That seems not a good idea in my eyes,
because you always must assume that the reference shows to null and
you always need a fallback strategy. This is really tricky to test.
Has Ebean such tests?
How ever it's hint how to reproduce this behavior. Just run with
small memory.

Niels

[Mario Ivankovits]

Hi!

Sorry, I don't remember which version of ebean you use. But this issues definitely has been fixed. I am aware of it and haven't seen it for a long time now.
I would bet this has is fixed in the latest release either .... else with SVN HEAD this issue should no longer exist.

If so, and it is not yet release, we should release ebean very soon.

Ciao,
Mario

> -----Ursprüngliche Nachricht-----
> Von: eb...@googlegroups.com [mailto:eb...@googlegroups.com] Im
> Auftrag von PlayDeveloper
> Gesendet: Mittwoch, 12. Oktober 2011 14:31
> An: Ebean ORM
> Betreff: [ebean] Re: Ebean shows non deterministic behavior

[edge]

Well as Mario indicted we fixed a similar problem a while back - so if
you are not using the latest code then you should probably take the
latest code.
WeakRefernces are tricky and sometime not very intuitive so the
problem may not be completely fixed :( but we'll only know that if you
run the latest code.

On Oct 12, 2:30 pm, PlayDeveloper <opensourc...@googlemail.com> wrote:
> Hi,
>
> On 12 Okt., 10:56, edge <e.mcgr...@imilia.com> wrote:
>
>
>
>
>
>
>
>
>
> > hi Neils,
>
> > here just a few suggestions:
>
> > It sounds like a problem that we previously had (and I though we
> > fixed) - namely, we use weak references in the persistence context and
> > as far as I can remember the objects were being GC'ed and then missing
> > during the lazy loading resulting in properties being null.
>
> > So this is very tricky to track down - I think since you are using
> > Ebean a lot you should pull the code from SVN and compile locally and
> > then you could probably "doctor" the persistence cache to see if the
> > problem goes away. You probably won't easily be able to create a test
> > case to reproduce this - real apps are much more complex than test
> > cases and once you know what the problem is then the test case becomes
> > obvious :)
>
> If I understand you right, than you say that it probably fixed in the
> head of SVN?
>
> I assume that it is a problem of WeakReferences. Today we get a
> java.lang.RuntimeException: Nothing in batch?
>         at
> com.avaje.ebeaninternal.server.core.DefaultBeanLoader.loadBean(DefaultBeanL oader.java:

> 299)
>         at
> com.avaje.ebeaninternal.server.core.DefaultServer.loadBean(DefaultServer.ja va:
> 526)
>         at
> com.avaje.ebeaninternal.server.loadcontext.DLoadBeanContext.loadBean(DLoadB eanContext.java:

[PlayDeveloper]

We used 2.7.3. I tried to build the current head but the tests failed.

However I'm unsure if this behavior will be a blocker for further
evaluation. Unpredictable behavior is for me a big issue and
WeakReferences leads to such behavior. I think it necessary to force
the user of a function which based on WeakReferences to have always an
alternative strategy to get the data if the WeakReference is lost (I
guess isEnqueued do the job). It looks like this work wasn't done for
Ebean and I'm unsure how easily this could be added.
Look at

java.lang.RuntimeException: Nothing in batch?
at
com.avaje.ebeaninternal.server.core.DefaultBeanLoader.loadBean(DefaultBeanLoader.java:
299)

If you analyze the code and look where the batch is filled you will
see that it based on a WeakReference. So it could happens that the
batch is empty. Throwing a such a RuntimeException is in my opinion
not an appropriate behavior.

Sorry for this unfriendly words, but to be honest I'm really
disappointed. The first impression was so good and you have really
smart concepts, but now I fear we must rethink out strategy at the
project.

Niels

[Mario Ivankovits]

Well, this beast has been fixed already, probably just a release is missing. I use ebean head from around August and it works in an really, really IO intensive application without any problems.

I just ran a "mvn -Djdk=1.6 clean install" without an problems:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 53.371s
[INFO] Finished at: Wed Oct 12 22:07:54 CEST 2011
[INFO] Final Memory: 11M/135M
[INFO] ------------------------------------------------------------------------

It is worth fixing your issues, trust me ;-)

Ciao,
Mario

> -----Ursprüngliche Nachricht-----
> Von: eb...@googlegroups.com [mailto:eb...@googlegroups.com] Im
> Auftrag von PlayDeveloper

> Gesendet: Mittwoch, 12. Oktober 2011 20:29

> An: Ebean ORM
> Betreff: [ebean] Re: Ebean shows non deterministic behavior
>

> > > 143)
> > >         at
> > >
> com.avaje.ebean.bean.EntityBeanIntercept.loadBean(EntityBeanIntercept.j
> ava:
> > > 548)
> > >         at
> > >
> com.avaje.ebean.bean.EntityBeanIntercept.preGetter(EntityBeanIntercept.j
> ava :

[Rob Bygrave]

>> WeakReferences leads to such behavior

I'm not sure what you base this statement on. The weak references should only be GC'ed if there are no hard references to the same object (which should not be the case).

It is easy to jump to the wrong assumption when trying to diagnose an issue and that might well be happening here. 

>>

Look at

java.lang.RuntimeException: Nothing in batch?
       at com.avaje.ebeaninternal.server.core.DefaultBeanLoader.loadBean(DefaultBeanLoader.java:299)

<<

This is the place to start but remember we don't know anything about your application or your domain model and we don't have a test case yet. We do now know that you are actually seeing an exception though so that is helpful and gives us something to look at.

Cheers, Rob.

[PlayDeveloper]

Hi

On 12 Okt., 22:10, Mario Ivankovits <ma...@datenwort.at> wrote:
> Well, this beast has been fixed already, probably just a release is missing. I use ebean head from around August and it works in an really, really IO intensive application without any problems.
>

I think a lot of IO isn't the problem. Here we don't have an threading
problem. It's looks for me like an memory-problem in the application.
So if the application needs a lot of memory (we have a batch job) then
you get the problems. We transport a aggregation job from grails to
Ebean. Starting for 10 days and have 2 issues.

> I just ran a "mvn -Djdk=1.6 clean install" without an problems:

You are right running with java 1.6 it runs well. I run it with JDK1.5
and get the failures in test.

>
> It is worth fixing your issues, trust me ;-)

Well we have now a running application. We used fetch statement to
prevent lazy-loading and increase the memory.

Niels

[PlayDeveloper]

Hi Rob,

On 12 Okt., 22:39, Rob Bygrave <robin.bygr...@gmail.com> wrote:
> >> WeakReferences leads to such behavior
>
> I'm not sure what you base this statement on. The weak references should
> only be GC'ed if there are no hard references to the same object (which
> should not be the case).
>
> It is easy to jump to the wrong assumption when trying to diagnose an issue
> and that might well be happening here.
>

Well I based my critics on the usage of WeakReferences based on a talk
of Angelika Langer (http://www.angelikalanger.com) which is a well-
known in Germany and can explain the GC in detail. And she warn for
the usage, because it can end errors which are difficult to analyze.
However it's the same like Threads. Sometimes you really need them,
but you get the risk, that you run into errors, which are really ugly
to analyze. The problem starts with the issue that I can't write Unit-
Tests for it (at least I don't know how). So I was a little bit
irritated about the many usages of it and I don't know how we could
protect Ebean-users in the future.

>
> Look at
> java.lang.RuntimeException: Nothing in batch?
>
>  at com.avaje.ebeaninternal.server.core.DefaultBeanLoader.loadBean(DefaultBeanLoader.java:299)
> <<
>
> This is the place to start but remember we don't know anything about your
> application or your domain model and we don't have a test case yet. We do
> now know that you are actually seeing an exception though so that is helpful
> and gives us something to look at.

Just to clarify: I found the support at Ebean really great and better
than by hibernate, where you get more answers but sometimes of bad
value. We have now fixed the production problem and concentrate on
creating a test case. I hope we can deliver it today, but it's a
really tricky-job. We will investigate another day to try to clarify
the problems and check if the new version fix the issues.

Niels

[Durchholz, Joachim]

> Well I based my critics on the usage of WeakReferences
> based on a talk of Angelika Langer (http://www.angelikalanger.com)
> which is a well- known in Germany

Not to me, despite being in Germany myself.
Do you have a link? Google search for Angelika Langer and weak references didn't give me a link to the article, just a lot of pages that mention weak references in passing.

> However it's the same like Threads. Sometimes you really
> need them, but you get the risk, that you run into errors,
> which are really ugly to analyze.

Hmm... this may sound Draconian, but I'd design my unit tests so that they load a library that replaces the WeakReference class with one that always returns nulls.
That way, any bugs of the kind you have experienced will be instantly and reproducably reproduced.
I'm somewhat sceptical of code that retrieves objects from a weak reference and assumes that a strong reference exists. Either the code knows about a concrete strong reference that keeps the weak one alive, then it should use the strong reference; or it does not, then it has no business assuming the weak reference is not null. The middle ground - code knows a strong reference exist but can't easily access it - sounds like a design that might break with the next refactoring.

Again, just my 2 cents.

Regards,
Jo

[Rob Bygrave]

FYI

I have refactored some code to simplify things, added some better logging and some code to more clearly detect this possible situation - plus a flag to switch between weak and hard references. Also added some test cases using System.gc() checking the weakreferences are maintained as you'd expect and not without any hard references in scope etc.

As to the why Ebean uses weak references - that is a longer explanation for later.

Cheers, Rob.

[PlayDeveloper]

Hi after long frustrating day this sounds good. FYI our status:
The problem with "java.lang.RuntimeException: Nothing in batch? " is
fixed in the current version. That's good.

However the problem with the nullpointer is still there. We tried to
reproduce the problem in an example with no success. The debugging
approach fails too. we start thinking to change the code so much so
that we can deliver it to you, but the problem is, that it only
happens with a special database constellation. So even if I send you
the code this wouldn't enable you to reproduce the error. The data on
the other side I'm not allowed to give third-parties :-(
Another problem is that the exception only comes after 6 minutes. So
every test cost a lot of time :-(

I will look at your changes and will try to give you more information.

Thanks for all your support!

Niels

On 13 Okt., 14:36, Rob Bygrave <robin.bygr...@gmail.com> wrote:
> FYI
>
> I have refactored some code to simplify things, added some better logging
> and some code to more clearly detect this possible situation - plus a flag
> to switch between weak and hard references. Also added some test cases using
> System.gc() checking the weakreferences are maintained as you'd expect and
> not without any hard references in scope etc.
>
> As to the why Ebean uses weak references - that is a longer explanation for
> later.
>
> Cheers, Rob.
>
> On 14 October 2011 00:29, Durchholz, Joachim <
>

[Rob Bygrave]

Can you give the stack trace ... or as much of the stack trace as you can?

Thanks, Rob.

[PlayDeveloper]

Hi Rob,

the problem is that in the stacktrace you don't find any Ebean-
information. How ever my colleague tracks the thing more, with the
debugger. Here is the result of her analysis.

She set a break-point where the object was null and analyze the entity-
object. As a result she found out that
EntityBeanIntercept has an inconsistent state: loaded=false and
lazyLoadProperty="name" normally it should be null.

So here our theory what happens (no idea why and how)

Assume we have the following relations
Customer has many Orders
Order has Many OrderDetails
OrderDetail refers a Product (one or many)

Product can be referred by many OrderDetails.

Now you navigate from Customer-Objekt to a Product-Objekt and ask for
the name with product.getName(), which ends in a Lazy-Loading.
This means
1. product.getName() triggers
com.avaje.ebean.bean.EntityBeanIntercept.preGetter("name")
2. In EntityBeanIntercept-Objektes the flag loaded is false and
lazyLoadProperty == null
3. com.avaje.ebean.bean.EntityBeanIntercept.loadBean("Name") will
called
4. lazyLoadProperty will be set to "name"
5. beanLoader.loadBean(this) will be called
6. for some reasons there will after loading neither the method
setLoaded() nor setLoadedLasy() be called! (There was no exception
found.)
7. EntityBeanIntercept is an inconsistent state: loaded=false and
lazyLoadProperty="name"
8. the call of product.getName() delivers null
9. Our program crashes, because name is notnullable so we assert that
it is not null (Which is correct if we looked into the database).

So the question is. how could we produce the inconsistent state.

I hope the description is clear enough and give you a hint where you
can look.

Here the last entry from sql-log (Translated to the example)
txn[1002], 10:53:07.523, FindMany mode[+lazy] type[Product]
origin[CEFTff.Dbglul.BwwVXh] lazyLoadProp[name]
load[path:customer.order.orderDetailsbatch:1 actual:1] exeMicros[243]
rows[1] name[] predicates[t0.id = ? ] bind[5157]

Despite that the name is null, direct after that:-/

Regards
Niels

On 13 Okt., 22:13, Rob Bygrave <robin.bygr...@gmail.com> wrote:
> Can you give the stack trace ... or as much of the stack trace as you can?
>
> Thanks, Rob.
>

[PlayDeveloper]

In revision 1344 we get a new exception
java.lang.IllegalStateException: getLoadBatch position[2] didn't find
a bean in the list?
at
com.avaje.ebeaninternal.server.loadcontext.DLoadWeakList.getLoadBatch(DLoadWeakList.java:
89)
at
com.avaje.ebeaninternal.server.loadcontext.DLoadWeakList.getLoadBatch(DLoadWeakList.java:
75)
at
com.avaje.ebeaninternal.server.loadcontext.DLoadBeanContext.loadBean(DLoadBeanContext.java:
160)
at
com.avaje.ebean.bean.EntityBeanIntercept.loadBean(EntityBeanIntercept.java:
487)
at
com.avaje.ebean.bean.EntityBeanIntercept.preGetter(EntityBeanIntercept.java:
578)

at model.AttributeValue._ebean_get_name(AttributeValue.java:4)
at model.AttributeValue.getName(AttributeValue.java:42)

which goes in the right direction, because if you don't get the batch
the data wouldn't be loaded.

I think the batch is lost because it was a weak-reference. The
exception only happens if we limited the memory.

Niels

[Rob Bygrave]

I built an application that reproduced this issue and it is fixed in 3.3.1-RC1.

Refer to https://github.com/ebean-orm/avaje-ebeanorm/issues/74

 

[jmdi...@yahoo.com]

I have found the same behavior in 3.3.1.RC2

1. I have entities Product @ManyToOne TaxCategory, in databse there exists 4000+products and 35 taxcategories.

2. Using JDK1.7, plain java, no other framework (no web, nothing special, a simple swing application).

3. My simple test (works well, Category.toString return access and returns name property):

    @Test
    public void getProducts() {
        List<Product> l = EbeanDao.getProductDao().getProductos();

        for (Product p: l) {
            System.out.println("p.getTaxCategory() : " + p.getTaxCategory());
        }
    }


4. THIS DOES NOT WORK: In my Swing app I am trying to show a combo box with then current product.category selected, this does not work because m_product.getTaxCategory returns null (curiously in this way theres is no access to any TaxCategory attribute):

       this.m_jTax.setSelectedItem(m_product.getTaxtCategory()); 

5. BUT THIS WORKS OK (the only change is to acces an attribute from taxCategory):
       System.out.println("m_product.getTaxCategory() " + m_product.getTaxtCategory().getName());
       this.m_jTax.setSelectedItem(m_product.getTaxtCategory()); 

In summary, I think product.taxCategory is null until we really access a field from taxcategory, this is not the behavior expected, we expect product.taxCategory to return a valud reference to an entity (filled or not)....

I hope this help to advance this good library.

[Rob Bygrave]

Can you produce a test case for 4 ?

--
 
---
You received this message because you are subscribed to the Google Groups "Ebean ORM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ebean+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.