[
https://issues.apache.org/jira/browse/JDO-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970915#action_12970915
]
Erik Bengtson commented on JDO-667:
---
This method should check for permission, otherwis
JDOUserException.
Any thoughts?
Erik
API implemented in Javascript
-
Key: JDO-659
URL: https://issues.apache.org/jira/browse/JDO-659
Project: JDO
Issue Type: New Feature
Reporter: Erik Bengtson
Creatre an implementation of the API in
+1 Release JDO.next specification
+1 Rename JDO.next to JDO 3.0.
+1 Rename maven artifact from jdo2-api to jdo-api
On Fri, Apr 30, 2010 at 3:38 AM, Craig L Russell
wrote:
> I've looked at the changes for JDO 2.3 and I agree with others that the
> changes are pretty significant in terms of new cap
If you provide a query parameter and lock the parameter object in your
thread, you might be able to have the other thread waiting you to
unlock, so you can execute the cancel.
On Sun, Mar 14, 2010 at 7:50 PM, Michael Bouschen wrote:
> Hi Andy, hi Craig,
>
> I'm surprised about the query execution
>Attendees: Michelle Caisse, Richard Schilling, Craig Russell
>An interesting option for a JDO implementation is to use a RESTful
>service like Amazon S3 or memcached for the back end. Some obvious
>issues are transactions, object identity, and query. But having an
>object front end for these woul
t apply to the
> database processing and not include the preparation or post-query
> processing.
>
>
I dont agree. The user sets a timeout on the total execution of the
operation, and not only on part of it. For example DataNucleus can compile
and evaluate queries in memory, so it never leaves the JDO implementation.
In my opinion we should have two timeout settings: connection timeout and
execution timeout. Execution timeout includes connection timeout.
To me it's also clear that these timeouts should be applicable to all JDO
persistence operations and not only to the query.
However, you might want to mirror JPA functionality, but it's too RDBMS
minded.
Erik
Another way of disabling the enhancement on compile time is removing the
enhancer jar from the compiler classpath.
On Tue, Jun 30, 2009 at 4:28 PM, Michael Bouschen wrote:
> Hi Andy,
>
> you recently added the following line to projects.properties in tck2 in
> order to turn OFF any post-compil
>Why would you want to have two different fields for the same
>association? As far as I can see, it would always hold true that
>b.a1==b.a2. You could express that in OCL in your UML, but in most cases
>in the jdo metadata the above would be an error. You could still have
>another getter getA2() re
>in the XML metadata, it is possible to have multiple FCO fields, e.g.
>B.a1 and B.a2, with identical mapped-by pointing to the same field of
>the same related class, e.g. A.b. In effect this would theoretically
>mean that the FK should be shared among different associations in the
>object model.
NBCb
--Original Message--
From: Andy Jefferson (JIRA)
To: jdo-dev@db.apache.org
ReplyTo: jdo-dev@db.apache.org
Sent: 7 Apr 2009 18:28
Subject: [jira] Commented: (JDO-627) Tests for One-Many-Bidir with jointable
mapping
[
https://issues.apache.org/jira/browse/JDO-627?page=com.atlassi
Hi,
You might be interested to know that DataNucleus HEAD can enhance classes
during compilation/javac.
The trick is supported from J2SE 1.6 and upper. Also tested in Eclipse IDE.
Who will complain about the enhancement step now?
Regards,
Erik
K run rules?
Regards,
Erik
[
https://issues.apache.org/jira/browse/JDO-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Bengtson deleted JDO-602:
--
> Bundle-ManifestVersion entry in Manifest.MF file has a trailing space that
> causes problems to som
://issues.apache.org/jira/browse/JDO-602
Project: JDO
Issue Type: Bug
Components: api2, api2-legacy
Affects Versions: JDO 2 maintenance release 1
Reporter: Erik Bengtson
Assignee: Erik Bengtson
Fix For: JDO 2 maintenance release 2
The
[
https://issues.apache.org/jira/browse/JDO-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591393#action_12591393
]
Erik Bengtson commented on JDO-591:
---
The enhancer API should implement the javaagent ja
My wish list are the features that could differentiate JDO to JPA:
- support to multiple datastores
- JMX management/monitoring model
- OSGi Service (Similar to JDO-556)
- The long waited enhancer API
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : mardi 1 a
If the decision factor was based on not being a Sun competitor, then the
first choice would be JPOX.
...lobbing was key.
-Message d'origine-
De : Matthew Adams [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 20 mars 2008 17:58
À : jdo-dev@db.apache.org
Objet : Re: [VOTE] Release Apache JDO 2.1
p;pid=1
0111&fixfor=10312
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : mardi 18 mars 2008 23:29
À : Erik Bengtson
Cc : 'JDO Expert Group'; 'Apache JDO project'
Objet : Re: [VOTE] Release Apache JDO 2.1
Hi Erik,
We've
+1.
JPOX 1.2.1 is the version to label as JDO 2.1 reference implementation.
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : mardi 18 mars 2008 22:10
À : JDO Expert Group; Apache JDO project
Objet : [VOTE] Release Apache JDO 2.1
This vote is to release the A
[
https://issues.apache.org/jira/browse/JDO-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579072#action_12579072
]
Erik Bengtson commented on JDO-582:
---
> It applies to 8 files now with the 2.1 bran
[
https://issues.apache.org/jira/browse/JDO-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Bengtson resolved JDO-581.
---
Resolution: Fixed
Fix Version/s: JDO 2 maintenance release 1
> Undecipherable error message f
Reporter: Erik Bengtson
Assignee: Craig Russell
Fix For: JDO 2 maintenance release 1
Attachments: estedExceptionJDOHelper.patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[
https://issues.apache.org/jira/browse/JDO-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Bengtson updated JDO-582:
--
Attachment: estedExceptionJDOHelper.patch
> JDOFatalException nested argument needs cast to Throwa
+1 make the change now
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 25 janvier 2008 18:13
À : Apache JDO project; JDO Expert Group
Objet : [VOTE] Change signature of new method evictAll
We have a method new for JDO 2.1 in PersistenceManager and
The implementation can do the necessary in 1 or more statements as you said.
-- BlackBerry® from Mobistar---
-Original Message-
From: Michael Bouschen <[EMAIL PROTECTED]>
Date: Sun, 09 Dec 2007 22:22:27
To:Apache JDO project
Cc:JDO Expert Group <[EMAIL PROTECTED]>
Subject: Re: Q
Craig,
what's the meaning of this? Something to do with non tx writes?
"...It must write the before image of dirty instances in order
to restore these instances later"
[
https://issues.apache.org/jira/browse/JDO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Bengtson updated JDO-552:
--
Attachment: JDO-552.patch
> JDOFatalDataStoreException, JDOObjectNotFoundException
[
https://issues.apache.org/jira/browse/JDO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Bengtson reassigned JDO-552:
-
Assignee: Erik Bengtson
> JDOFatalDataStoreException, JDOObjectNotFoundException
[
https://issues.apache.org/jira/browse/JDO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543648
]
Erik Bengtson commented on JDO-552:
---
All JDO exceptions, except the above, take an array of Throwable and a failed
--
Key: JDO-552
URL: https://issues.apache.org/jira/browse/JDO-552
Project: JDO
Issue Type: Improvement
Components: api2
Reporter: Erik Bengtson
Priority: Trivial
These 3 exceptions have constructors
From: Matthew Adams <[EMAIL PROTECTED]>
Date: Mon, 5 Nov 2007 16:12:04
To:Erik Bengtson <[EMAIL PROTECTED]>
Cc:jdo-dev@db.apache.org,[EMAIL PROTECTED]
Subject: Re: jdo security revamped proposal
Hi Erik,
While I think this is an ingenious use of Java platform security, I
can'
Hi,
After negative feedback, I have a different proposal for securing JDO
resources.
Different from my initial proposal using declarative security (XML), here I
propose using the standard java security.
The example is self-explaining:
--- Persistent Class sample:
package com.petstore;
class Pet
ssage-
From: Joerg von Frantzius <[EMAIL PROTECTED]>
Date: Mon, 05 Nov 2007 10:28:55
To:jdo-dev@db.apache.org
Cc:[EMAIL PROTECTED]
Subject: Re: multiple databases one PM/TX
Hi Erik,
there is one thing that I don't understand about this proposed feature
(which may be just me not seeing t
Another use case of enum persistence, is the persistence of arbitrary
values.
public enum Test {
RED(1), BLUE(5);
private final int value;
Test(int v)
{
this.value = v;
}
public final int getValue()
{
return this.value;
}
pub
otherwise:
SELECT this.images#value
FROM Item
WHERE {'thumbnail', 'full', 'high-res'}.contains(this.images#key)
-Message d'origine-
De : Matthew Adams [mailto:[EMAIL PROTECTED]
Envoyé : mardi 30 octobre 2007 21:58
À : Erik Bengtson
Cc : 'Apache
Interesting that you mention Maps on queries, because I have another
proposal.
The example says all:
Map result = (Map) pm.newQuery("SELECT new Map FROM
Person").execute();
result.get("jordan") returns Person[name=jordan,firstName=michael]
result.get("simpson") returns [ Person[name=simpson,f
>This is one of the last items before we release JDO 2.1.
>We need to specify the behavior of a persistence manager if it
>implements Serializable and its writeObject method is called.
Couple of questions.
Portability:
Do we look after portability on serialization? I mean, can PM of
implemen
policies.
However we need a framework to cope with data access and I dont see any
light of that coming from a std committee.
Regards
De : Eric Samson [mailto:[EMAIL PROTECTED]
Envoyé : lundi 29 octobre 2007 17:13
À : Erik Bengtson; jdo-dev@db.apache.org; [EMAIL PROTECTED]
Objet : RE
I would like also to get some feedback about controlling access to data in a
standard JDO:
- Users should be able to specify fine grained access control to
persistent
objects.
- JDO implementations raise exceptions if the authenticated user does not
fit
into the role specified in the
and enhancement.
>
> [May 25 2007] AI Matthew Adams prepare a proposal with just the basics
> of schema synchronization with jdo and orm metadata.
>
> [May 18 2007] AI Craig update http://wiki.apache.org/jdo/
> CurrentDevelopment wiki page
>
> [Apr 27 2007] AI Craig re
No comments about buyout, but patrick would be welcome to our team in setting
up a data access platform in heterogeneous data stores for soa, data analysis,
mining and ofcourse operational usage. Doh!
-- BlackBerry® from Mobistar---
-Original Message-
From: David Jordan <[EMAIL PRO
Type: Bug
Components: api2
Reporter: Erik Bengtson
Priority: Minor
--- Craig says:
Hi Erik,
Actually, this is a bug in JDOImplHelper. It is missing a
doPrivileged around calling getDateTimeInstance.
The permissions you mention should be assigned to the JDO
An application using JDO needs the following additional permissions to run:
permission java.util.PropertyPermission "user.country", "read";
permission java.util.PropertyPermission "user.timezone",
"read,write";
permission java.util.PropertyPermission "java.home", "read";
O
Should be fixed in CVS
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 28 septembre 2007 19:21
À : jdo-dev@db.apache.org
Objet : Enhancer error with spaces in path names
Hi Andy,
After downloading new jpox jars, I started getting the following erro
>2. Review PMF bootstrap process for JDO specification. Feedback was
>received from Matthew. Other issues are whether there is a need for
>getPMF(Map, ClassLoader, ClassLoader) and whether you can use a Map
>plus a String pmf name. AI Matthew provide examples for 8.6.1.1
>jdoconfig.xml.
I
Hi,
There is a commentary in the XSD for the unique element saying that either
, or can occur, however there are several cases
we would like to mix these elements. IMO this limitation should not exists.
To illustrate:
Abstract class Person
{
abstract getName();
abstract setName();
String getLas
[
https://issues.apache.org/jira/browse/JDO-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524808
]
Erik Bengtson commented on JDO-523:
---
Looks good, but it has a typo in "unitnamed" and a dot is missing at
[
https://issues.apache.org/jira/browse/JDO-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Bengtson updated JDO-523:
--
Summary: Misleading error msg raised by
JDOHelper.getPersistenceManagerFactory(arg) if the resource in
://issues.apache.org/jira/browse/JDO-523
Project: JDO
Issue Type: Improvement
Components: api2
Affects Versions: JDO 2 maintenance release 1
Reporter: Erik Bengtson
> Running the following code, and if the jpox.properties cannot be
> found, a
> m
Hi,
Running the following code, and if the jpox.properties cannot be found, a
misleading message is raised that indicates a missing a EntityManager
persistence provider, but should actually tell me that my resource
jpox.properties cannot be found.
PersistenceManagerFactory pmf =
JDOHelper.getPers
ExpandoMetaClass that
> > has the magic to avoid reflection and enhancement.
> >
> > [May 25 2007] AI Matthew Adams prepare a proposal with just the
> > basics of schema synchronization with jdo and orm metadata.
> >
> > [May 18 2007] AI Craig update http://wiki.apac
Hi,
§18.14
"When contained in a class element:
- The field-name attribute is required; it associates a persistent field with
the named property."
AFAIR field-name attribute is used for generated classes. It should be optional
when contained in class or interface elements.
e.g.
//user given inte
Richard,
If you are searching for the internals of a JDO implementation, you can read the
JPOX internals at
http://jpox.cvs.sourceforge.net/*checkout*/jpox/JPOX/xdocs/1_1/developer/jpox-core.odp
Regards,
Quoting Richard Schilling <[EMAIL PROTECTED]>:
> I did realize that the JDO API and the mod
Ops,
This is already in the spec §21.6
Quoting Erik Bengtson <[EMAIL PROTECTED]>:
> Craig,
>
> I don't mean any changes to attachment or detachment detection. Once the
> jdoDetachedState is lost, attachment will not work.
>
> My proposition (serialization) is alre
s
the serialVersionId it becomes compatible (enhanced vs non-enhanced), but the
jdoDetachedState is lost.
Regards,
Quoting Craig L Russell <[EMAIL PROTECTED]>:
> Hi Erik,
>
> The way to send objects to a remote site using the standard
> serialization contract is to define the cl
> Hi Erik,
>
> These are implementation details. Can you explain what the user
> behavior is, and the use case?
>
> Thanks,
>
> Craig
>
> On May 7, 2007, at 5:31 PM, Erik Bengtson wrote:
>
> > Craig,
> >
> > There are two cases: Clas
(jdoDetachedState) //enhanced
}
private readObject (OutputStream os)
{
//user serialization
jdoDetachedState = os.readObject(); //enhanced
}
Quoting Craig L Russell <[EMAIL PROTECTED]>:
> Hi Erik,
>
> It would help if you could explain what you have in mind with this
> change. Th
version of
the class, the detached state is dropped and no further read or change tracking
will occur on the unmarshalled instance."
Regards,
Erik Bengtson
Quoting Andy Jefferson <[EMAIL PROTECTED]>:
> > Another issue: deletePersistentAll((Object[]) null) (and similars
> > operations) behavior not specified if arg is null
>
> See 12.6 at the end "Null management".
>
Andy,
That section refers to PM methods and only with arguments Object or Object[].
Michael,
I've changed my mind, and now I think we should fix the XSD, having strict
checks and lose flexibility, instead of having the jdo implementation do more
checking. It's just too long to implement/maintain/test, prone to errors and
costs in performance.
I propose the extension element to b
Hi,
JDO does not specify the null argument handling behavior on these cases:
Query.execute((Object[])null)
Query.execute((Map)null)
Query.deletePersistentAll((Object[])null)
Query.deletePersistentAll((Map)null)
IMO it should raise JDOUserException.
Regards,
Erik Bengtson
Hi,
Is the new JDO "Transaction Type" equivalent to JPA in semantics? In JPA,
Transaction Type=JTA means that the implementation will join a JTA transaction
if one exists, is that the same in JDO?
JPA also has a EntityManager.joinTransaction method..
Regards,
Erik Bengtson
> So how about adding a flag that defaults to true if not specified to
> enlist the datastore connection in the datastore transaction?
sounds good
Hi,
This is a change proposal to the spec with regards to enlistment of native
connections when optimistic transactions are used.
The enlistment of native connections into a JDO transaction is conditioned to
the fact that a flush call has been performed before the connection is
obtained.
The fl
> I'm afraid I don't know what you mean by "this feature" and "this
> change". If you want to guarantee that the datastore connection you
> get is enlisted in the JDO transaction
tx.setOptimistic(true)
tx.begin()
//do some operations here
JDOConnection conn = tx.getDataStoreConnection();
conn.getN
Quoting Craig L Russell <[EMAIL PROTECTED]>:
> This is a backward-incompatible change. But maybe we should consider
> to request a datastore connection that would have that semantic by
> adding a boolean flag to the getDataStoreConnection method indicating
> that you want to be able to perform tra
I have an optimistic transaction and I access the datastore connection. I
perform some updates/inserts and rollback the transaction. The changes are not
rolled back since the connection/transaction was not enlisted in the JDO
optimistic transaction. This behavior is correct according the below para
sun jvm build 1.5.0_10-b03
Testcase:
testNegative1_NoPersistenceUnitsDefined(javax.jdo.JDOHelperConfigTest): Caused
an ERROR
loader constraints violated when linking org/w3c/dom/Node class
java.lang.LinkageError: loader constraints violated when linking
org/w3c/dom/Node class
at
javax.jdo
The test asserts transaction of pc-non trans dirty to transient on
serialization. I understand it should have been pc-non trans dirty to detached
clean (matching pc-dirty and pc-non trans states behavior)
1)
test(org.apache.jdo.tck.lifecycle.StateTransitionsReturnedObjects)junit.framework.Assertio
Hi,
The TCK asserts for pnon-trans-dirty instances that it transition to transient
on on serialization.
On serialization, pc-dirty and pc-nontrans transitions to detached clean.
I could not find anything on the spec saying that it must become transient. Is
this a bug in the TCK?
Erik Bengtson
[
https://issues.apache.org/jira/browse/JDO-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485777
]
Erik Bengtson commented on JDO-474:
---
JORM is not a JDO implementation, but the core of Speedo.
xorm.org seems to be
[
https://issues.apache.org/jira/browse/JDO-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485709
]
Erik Bengtson commented on JDO-390:
---
The test checks whether a SCO field is transient. SCO wrapper instances should
)
-
Key: JDO-473
URL: https://issues.apache.org/jira/browse/JDO-473
Project: JDO
Issue Type: Wish
Components: specification
Affects Versions: JDO 2 final
Reporter: Erik Bengtson
Craig, we have other tasks that we are working on for 2.1, like sub queries and
persistent properties
Quoting Craig L Russell <[EMAIL PROTECTED]>:
> There's still a bunch of work going on in the api20 workspace that
> will go into both the api2 and api2-legacy workspaces. Is JPOX being
> held up
setBirth(Date birth)
{
this._birth = birth;
}
}
If an exception is raised from the getter/setter, what should be done by the
implementation?
In JPA, there is an automatic rollback.
Regards,
Erik Bengtson
For implementations that support multiple databases in the same PMF, it would be
nice to allow in the XML to define multiple group of properties e.g.
The config name is used by JDO metadata to match the database it belongs to,
with adding a kind of config refer
Quoting Craig L Russell <[EMAIL PROTECTED]>:
> o the interface must be mapped to a table; portable applications will use the
> table attribute for this purpose
pc classes too. (inheritance strategy applies equals)
> o all persistent properties must be mapped to columns; portable applications
> w
What's RESOURCE_LOCAL? Non JCA?
Quoting Craig L Russell <[EMAIL PROTECTED]>:
> Please review and comment on this proposed change to the
> specification, as part of the JDO 2.1 maintenance release.
>
>
> (PersistenceManagerFactory interface)
> 11.3.1 Access via proxy
> PersistenceManager getPersi
lt;[EMAIL PROTECTED]>:
> Erik Bengtson wrote:
> > I don't think the spec prohibits multiple dbs in the backend, so my
> > concern is to not difficult it
> >
> The spec allows for multiple DBs in the backend, with a single PMF for
> each of them (or what backend we
I don't think the spec prohibits multiple dbs in the backend, so my
concern is to not difficult it
Quoting Joerg von Frantzius <[EMAIL PROTECTED]>:
> Hello Erik,
>
> this seems to be connected to thread Transaction Manager and JCA
> <http://www.jpox.org/servlet/fo
Craig, I understand that server means the backend database server. what it we
have multiple backend db servers?
Use case with multiple dbs:
SELECT FROM db1.classA WHERE classA.time > datetime() && classB.time >
datetime() VARIABLES db2.classB
The first datetime() is evaluated by db1, while the s
I have some questions regarding persistent interfaces.
1) If a class implements (in the Java sense via the 'implements'
clause), an interface that is declared persistent-capable in the
metadata, does the corresponding element in the metadata also
required to have a corresponding element or is th
> For OSGi containers, in addition to having the JDO jar compliant,
> some additional infrastructure is needed, for example the
> implementation jar should also contain a service definition for JDO.
> AI Erik write up proposal for the group.
>
Proposal for J2SE Service Discovery a
Looks like repository has moved...
"301 Moved Permanently - The requested resource has been assigned a new
permanent URI and any future references to this resource SHOULD use one of the
returned URIs."
Quoting Michelle Caisse <[EMAIL PROTECTED]>:
> When I attempt to build tck20, I get errors ret
Why not? Have you tried with JPOX ?
Quoting Luca Garulli <[EMAIL PROTECTED]>:
> Hi,
> Working in real-world applications using JDO 2.0 I beware about the SQL IN
> equivalend operator missed by spec. An example:
>
> public class Questionnaire{
> ...
> private Employee employee;
> ...
> }
>
>
> 2. Suggestion for new PMF setting javax.jdo.ClassLoader
>
> From Erik: When a JDBC driver is not loaded by the classloader ruled
> by JDO, there is no standard trick to make it work besides
> implementing the object factory (DriverManager is not designed for
> complex class
> 2. Suggestion for new PMF setting javax.jdo.ClassLoader
Sorry, I forgot my mobile at home and wont be able to join the meeting today.
Hopefully, the requirements I described were clear enough for discussion...
metadata
Thanks,
Erik Bengtson
general use (it is the last one in search order). Do you think we
could make this in the standard?
javax.jdo.ClassLoader which takes a java.lang.ClassLoader as value.
Regards,
Erik Bengtson
Craig,
Isnt it possible to have a jar with dual compatibility? Previous
classes are 1.3 binary compatible and the annotation classes are 1.5?
Erik Bengtson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 04, 2006 10:37 PM
To: Apache JDO
>
> Erik,
> I think the spec should not specify the evaluation order unless the
> semantics of the query is affected. Theoretically you could join the set
> of A instances with the set of all strings stored in the database and
> then evaluate the restriction. The result would be
by the JDO implementation the second one is certainly
the fastest.
I agree that this way the query should work, but needs clarification in the spec
on the evaluation order (unless I missed it).
Quoting Michael Bouschen <[EMAIL PROTECTED]>:
> Hi Erik,
>
> I fully agree with Craig&#
Craig,
I understand that variables of PC get bound to a set of pc type, but strings...
What is it bound to?
rgds
Quoting Craig L Russell <[EMAIL PROTECTED]>:
> Hi Erik,
>
> On Oct 28, 2006, at 7:19 AM, Erik Bengtson wrote:
>
> > Michael,
> >
> > I was readin
are valid, but I would like to double
> > check this. If you agree that the queries are valid JDOQL, I will
> > check the TCK to add these queries to existing TCK tests or add new
> > test cases. I tried the queries with JPOX version 1.1.3 and with
> > the nightly bui
Quoting Michael Bouschen <[EMAIL PROTECTED]>:
> The following query groups the class A instances by the strings in their
> string collection:
> Query q = pm.newQuery(A.class);
> q.declareVariables("java.lang.String str");
> q.setFilter("this.stringCol.contains(str)");
> q.setGrouping("str"
ECTED]>:
>
> --matthew
>
> >-Original Message-
> >From: Erik Bengtson [mailto:[EMAIL PROTECTED]
> >Sent: Friday, October 20, 2006 12:07 PM
> >To: jdo-dev@db.apache.org; [EMAIL PROTECTED]
> >Subject: RE: Feature proposal for JDO 2.1 maintenance: current D
> I don't think that aligning with JPOX's JDOQL extensions is a goal of the
> spec. :)
We can always try :)
I'm happy with any expression, date(), currentDate(), Date.getDate(),
JDOHelper.getDate(), etc.
Quoting Matthew Adams <[EMAIL PROTECTED]>:
> Hi Erik,
&
t;
> >>>>> lastModification timestamp before committing it.
> >>>>>
> >>>>> Regards,
> >>>>> Jörg
> >>>>>
> >>>>> Craig L Russell schrieb:
> >>>>>
> >>>>>
> >>&g
an use it e.g. for
> >> lastmodification timestamps and the like.
> >>
> >> Regards,
> >> Jörg
> >>
> >> Craig L Russell schrieb:
> >>> It's easy enough to define "new Date()" as being evaluated on the
> >>>
1 - 100 of 348 matches
Mail list logo
