Hi,

We will have our regular meeting Friday, August 12  at 9 am PST to
discuss JDO TCK issues and status.

Dial-in numbers are:

866 230-6968   294-0479#
International: +1 865 544-7856

Agenda:

Test status (Michael, Michelle)
JPOX fixes/issues (Erik)
Detached objects (Matthew)
Release of Apache JDO beta/snapshot (Craig, Brian T.)
Other  issues  and status (any and all)

Action Items from weeks past:

[Aug 5 2005] AI: Michelle, Michael W, Craig: Still need  to file JIRA
issues for new failures.

[Aug 5 2005] AI Brian McCallister can send info on the instructions how
to sync Apache and ibiblio.  Re: Brian Topping needs info on creating a
maven package.


[Aug 5 2005] AI: Karan: Issue with maven: renaming JPOX releases to
SNAPSHOT. Need to update the README file and project.xml file.

[Aug 5 2005] AI: Geoff look into alternative ways to get this project.
Re: Maven needs to checkout files from netbeans, not documented well.

[July 29 2005] AI: Michelle Chapter 18 wiki needs to be updated to
include all JDO metadata elements and attributes. [not done]

[July 29 2005] Inheritance proposal sent around by Michael. Needs to be
reviewed. 5 inheritance strategies. AI: Craig forward proposal to expert
group.

[July 29 2005] Is there any way to indicate from maven whether a set of
configurations was successful? Not the way it's set up. AI: Michael file
a JIRA on this.

[July 29 2005] (Craig, Brian T.) Need some permissions that Brian is
working on.

[July 22 2005] ? We need to enhance the DeepEquality class to allow
reporting of the difference reported. This will allow easier debugging
of mapping issues. Craig filed JIRA issue 109 on this.

[Jul 8]  Double-check locking in the PMF (Martin) Martin has implemented
and will check in.

[April 22 2005] AI JDO API release on ibiblio (Brian T)

[May 20 2005] AI: Craig file JIRA bug and fix this. Can test cases rely
on JDOHelper for state interrogation of non-binary-compatibility
classes? Yes, but the  JDO 2.0 JDOImplHelper class has not implemented
the functionality yet.

[April 15 2005] AI Brian Topping will update the wiki to tell how to
access our releases area.

[April 15 2005] AI Brian Topping will do the maven goal for creating and
uploading the snapshots. He will create a directory parallel to trunk
called "releases" and put the snapshots there.

[April 15 2005] AI Matthew will create a directory in the
tck.api.persistencemanager called detach in which he will have complete
freedom to implement the assertions in the detach section of the
specification.

[May 13 2005] AI Brian Topping will implement pushing SNAPSHOT builds of
the project to ibiblio.

[May 13 2005] AI Brian Topping will arrange for automated nightly builds
.

[May 13 2005] AI Martin Zaun will investigate JSR 294 (Java 5) to see
impact on enhancer.

[May 20 2005] AI Craig to define the JCP distributions and see if maven
can help.

-- Michelle

[ Post a follow-up to this message ]

Attendees: Michelle Caisse, Miichael Bouschen, Michael Watzek, Craig
Russell

1. Test status (Michael W)

Application identity 18 failures, 24 errors Datastore identity 17
failures 25 errors.

Mismatch in CollectionsCollections patch available.

Issue 106 is the biggest single problem. It is about mapping Object
fields, which are covered in the specification. Section 6.4.3 says
the implementation must support Object fields as First Class Objects.

We will resolve the issue of mapping collections of Object by
changing the .jdo file to identify collections of Object types as
collections of SimpleClass.

2. JPOX fixes/issues (Erik) Good progress.

3. Detached objects (Matthew) no status.

4. Release of Apache JDO beta/snapshot (Craig, Brian T.) AI: Craig to
propose release of API20 and the entire 11 release (API, RI, TCK).

Other  issues  and status (any and all)

5. Logging documentation is currently on the Wiki in its own page.
There are several loggers; we want to consolidate the logging. AI:
Michael.

6. Should we do cleanup in teardown or cleanup? Brian suggests doing
database cleanup during setUp; this has advantages that we should
explore. Perhaps a system property for CleanupAtSetup and another
CleanupAtTeardown? AI: Michael B reply to the email and start the
dialog.

Action Items from weeks past:

[Aug 5 2005] AI: Michelle, Michael W, Craig: Still need  to file JIRA
issues for new failures.

[Aug 5 2005] AI Brian McCallister can send info on the instructions
how to sync Apache and ibiblio.  Re: Brian Topping needs info on
creating a maven package.

[Aug 5 2005] AI: Karan: Issue with maven: renaming JPOX releases to
SNAPSHOT. Need to update the README file and project.xml file.

[Aug 5 2005] AI: Geoff look into alternative ways to get this
project. Re: Maven needs to checkout files from netbeans, not
documented well.

[July 29 2005] AI: Michelle Chapter 18 wiki needs to be updated to
include all JDO metadata elements and attributes. [not done]

[July 29 2005] Inheritance proposal sent around by Michael. Needs to
be reviewed. 5 inheritance strategies. AI: Craig forward proposal to
expert group.

[July 29 2005] Is there any way to indicate from maven whether a set
of configurations was successful? Not the way it's set up. AI:
Michael file a JIRA on this.

[July 29 2005] (Craig, Brian T.) Need some permissions that Brian is
working on.

[July 22 2005] ? We need to enhance the DeepEquality class to allow
reporting of the difference reported. This will allow easier
debugging of mapping issues. Craig filed JIRA issue 109 on this.

[Jul 8]  Double-check locking in the PMF (Martin) Martin has
implemented and will check in.

[April 22 2005] AI JDO API release on ibiblio (Brian T)

[May 20 2005] AI: Craig file JIRA bug and fix this. Can test cases rely
on JDOHelper for state interrogation of non-binary-compatibility
classes? Yes, but the  JDO 2.0 JDOImplHelper class has not implemented
the functionality yet.

[April 15 2005] AI Brian Topping will update the wiki to tell how to
access our releases area.

[April 15 2005] AI Brian Topping will do the maven goal for creating and
uploading the snapshots. He will create a directory parallel to trunk
called "releases" and put the snapshots there.

[April 15 2005] AI Matthew will create a directory in the
tck.api.persistencemanager called detach in which he will have complete
freedom to implement the assertions in the detach section of the
specification.

[May 13 2005] AI Brian Topping will implement pushing SNAPSHOT builds of
the project to ibiblio.

[May 13 2005] AI Brian Topping will arrange for automated nightly
builds.

[May 13 2005] AI Martin Zaun will investigate JSR 294 (Java 5) to see
impact on enhancer.

[May 20 2005] AI Craig to define the JCP distributions and see if maven
can help.

-- Michelle

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

[ Post a follow-up to this message ]

> Issue 106 is the biggest single problem. It is about mapping Object
> fields, which are covered in the specification. Section 6.4.3 says
> the implementation must support Object fields as First Class Objects.

OK, but the wording of that part of the spec was discussed in the EG back on
02 April 2005 (thread titled "updates to tck11 project", for those with EG
access) and the general conclusion was that it was totally vague, and maybe 
a
JDO implementation should be able to map "some PC type" to that Object field
but how it can be testable by the TCK is open to debate. How does the JDO
impl know that this Object field can only be a "SimpleClass" PC object
maybe ? There's no info that I can see in the metadata to define this.

It's the same problem space as interfaces. With those we have the "implement
s"
attribute which tells us which actual types we can store there. Consequently
JPOX models an interface field as being one FK for each implementation type
(so if there are 3 possible implementations, then the schema has 3 FKs). Wit
h
"Object" we have nothing to go on, so at the time of mapping the schema we
know that we may have to map something. Clearly the JDO implementation could
define an extension tag (akin to the JPOX "implementation-classes" that we
had for interfaces) that defines that this Object field can be represented b
y
these 2 PC types, but that becomes not testable by the TCK at that point.

If there's some action on JPOX from this, just let us know so we can work ou
t
what is needed.

--
Andy

[ Post a follow-up to this message ]

Hi Andy,

On Aug 12, 2005, at 12:16 PM, Andy Jefferson wrote:
 
>
> OK, but the wording of that part of the spec was discussed in the
> EG back on
> 02 April 2005 (thread titled "updates to tck11 project", for those
> with EG
> access) and the general conclusion was that it was totally vague,
> and maybe a
> JDO implementation should be able to map "some PC type" to that
> Object field
> but how it can be testable by the TCK is open to debate. How does
> the JDO
> impl know that this Object field can only be a "SimpleClass" PC object
> maybe ? There's no info that I can see in the metadata to define this.

Good point. I was thinking perhaps we should use the same technique
that we have already used to good effect with collections and maps.

What if we define a new attribute on field called field-type, and for
the TCK we put in "...SimpleClass"? Would that allow you to map it?

The issue is that Object types need to be supported, but as you point
out, there's not enough metadata to give an implementation a clue how
to do it.

What do you think? If it's doable, I can raise it to the jdo-experts.

Thanks for your quick feedback!

Craig

>
> It's the same problem space as interfaces. With those we have the
> "implements"
> attribute which tells us which actual types we can store there.
> Consequently
> JPOX models an interface field as being one FK for each
> implementation type
> (so if there are 3 possible implementations, then the schema has 3
> FKs). With
> "Object" we have nothing to go on, so at the time of mapping the
> schema we
> know that we may have to map something. Clearly the JDO
> implementation could
> define an extension tag (akin to the JPOX "implementation-classes"
> that we
> had for interfaces) that defines that this Object field can be
> represented by
> these 2 PC types, but that becomes not testable by the TCK at that
> point.
>
> If there's some action on JPOX from this, just let us know so we
> can work out
> what is needed.
>
> --
> Andy
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

[ Post a follow-up to this message ]

Hi Craig,

> Good point. I was thinking perhaps we should use the same technique
> that we have already used to good effect with collections and maps.
>
> What if we define a new attribute on field called field-type, and for
> the TCK we put in "...SimpleClass"? Would that allow you to map it?
>
> The issue is that Object types need to be supported, but as you point
> out, there's not enough metadata to give an implementation a clue how
> to do it.
>
> What do you think? If it's doable, I can raise it to the jdo-experts.

It certainly sounds doable (not looked at the code ...).
With an attribute like that we would have the same info as for an interface
and so we can do the same as we do there (and so a 1-1 relation where a clas
s
has an Object field marked as containing SimpleClass would result in a table
with a FK column across to the SIMPLECLASS table).

--
Andy

[ Post a follow-up to this message ]

Hi Andy,

On Aug 13, 2005, at 12:21 AM, Andy Jefferson wrote:

> Hi Craig,
>
> 
>
> It certainly sounds doable (not looked at the code ...).
> With an attribute like that we would have the same info as for an
> interface
> and so we can do the same as we do there (and so a 1-1 relation
> where a class
> has an Object field marked as containing SimpleClass would result
> in a table
> with a FK column across to the SIMPLECLASS table).

That's what I was thinking. I'll raise this issue to the expert group.

Thanks,

Craig
>
> --
> Andy
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

[ Post a follow-up to this message ]