On Jul 1, 2009, at 12:22 PM, Andy Jefferson wrote: >> QueryDSL already does that for JDOQL > http://source.mysema.com/display/querydsl/Querydsl Thanks for the pointer, Andy. QueryDSL looks cool but I'm not certain it's exactly what I'm looking for. In fact, their type-safe objects may be too extreme for my purposes. My general use case is that I present a GUI to the user with a large number of potential search criteria. When they hit the search criteria I want to build a query based upon what they have entered/selected. This query may involve complex nesting of ands and ors, which is one of the main problems I am trying to solve. I have hacked together something that generally works and is able to translate into a JDOQL query, but I was hoping that better minds had looked at the issue. Usually I am building the query on the fly - I rarely do preassembled queries based upon a specific query class.
> Are there any plans to add Query by Criteria to the JDO standard? I'm > referring to a programmatic API to build queries, similar to what > Hibernate already has and JPA is planning to add. > > If not, does anyone know of another route to achieving this > functionality? Are there any libraries that can be layered over JDO to > get this? Should I write my own? QueryDSL already does that for JDOQL http://source.mysema.com/display/querydsl/Querydsl I'm sure the guys who wrote it would love to hear feedback ;-) -- Andy DataNucleus (http://www.datanucleus.org)
Are there any plans to add Query by Criteria to the JDO standard? I'm referring to a programmatic API to build queries, similar to what Hibernate already has and JPA is planning to add. If not, does anyone know of another route to achieving this functionality? Are there any libraries that can be layered over JDO to get this? Should I write my own? Thanks for any insight.
Hi,
I have thought of this, but it sounded like an awful memory waste... it can rise to very high
memory consumption, just to keep this data around, like in the user session.
I also thought of using getObjectById to get the city object before persisting the address,
but that is another query hitting the DB (cache may help, but does not solve it).
Neither of these solutions sound nice... this is some pretty trivial operation, and there
should be a better solution for it. How can I do it? Could database identity help it somehow?
Thanks again!
--- Em seg, 29/6/09, Craig L Russell <Craig.Russell@Sun.COM> escreveu:
De: Craig L Russell <Craig.Russell@Sun.COM>
Assunto: Re: Persisting object and foreign keys
Para: jdo-user@db.apache.org
Data: Segunda-feira, 29 de Junho de 2009, 18:43
Hi,
If the combo box is populated from the database, perhaps you could keep a detached City object
around (as a value of a Map corresponding to the name of the city as the key) and when the
new Address instance is created, use the detached City instance as the value of the City field
in the new Address instance. When you do makePersistent on the Address, the detached City
instance will be reconnected to the database.
Craig
On Jun 29, 2009, at 12:54 PM, LFS wrote:
> Hi
>
> This is my situation: I have an Address object that I
> persist/retrieve from the DB. It contains a City object, reperesenting
> the city on which that address is. City contains State, and State
> contains Country object (a long N-1 chain).
> When I'm creating a new
> address from user input, the user selected its city from a combo box
> which I populated from DB, then I'll have the city's ID.
> When I try
> to persist the new address, the most I can do is put a City object on
> it, containing only the city ID. The problem is that persisting this
> will erase the City record for that ID on the DB, because other fields
> like Name and State will be null. I want simply to set the foreign id
> on the Address object, nothing else.
>
> I believe there is some
> good solution for this... my intention is not updating the City object,
> and retrieving it to put it back on the address object before being
> persisted sounds very strange and a performance nightmare.
>
> What's the proper way to do this?
>
> Thanks!
>
> Note: I'm using application identity and DataNucleus JDO.
>
>
> ____________________________________________________________________________________
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
Hi, If the combo box is populated from the database, perhaps you could keep a detached City object around (as a value of a Map corresponding to the name of the city as the key) and when the new Address instance is created, use the detached City instance as the value of the City field in the new Address instance. When you do makePersistent on the Address, the detached City instance will be reconnected to the database. Craig On Jun 29, 2009, at 12:54 PM, LFS wrote: > Hi > > This is my situation: I have an Address object that I > persist/retrieve from the DB. It contains a City object, reperesenting > the city on which that address is. City contains State, and State > contains Country object (a long N-1 chain). > When I'm creating a new > address from user input, the user selected its city from a combo box > which I populated from DB, then I'll have the city's ID. > When I try > to persist the new address, the most I can do is put a City object on > it, containing only the city ID. The problem is that persisting this > will erase the City record for that ID on the DB, because other fields > like Name and State will be null. I want simply to set the foreign id > on the Address object, nothing else. > > I believe there is some > good solution for this... my intention is not updating the City > object, > and retrieving it to put it back on the address object before being > persisted sounds very strange and a performance nightmare. > > What's the proper way to do this? > > Thanks! > > Note: I'm using application identity and DataNucleus JDO. > > > > ____________________________________________________________________________________ > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!
Hi
This is my situation: I have an Address object that I
persist/retrieve from the DB. It contains a City object, reperesenting
the city on which that address is. City contains State, and State
contains Country object (a long N-1 chain).
When I'm creating a new
address from user input, the user selected its city from a combo box
which I populated from DB, then I'll have the city's ID.
When I try
to persist the new address, the most I can do is put a City object on
it, containing only the city ID. The problem is that persisting this
will erase the City record for that ID on the DB, because other fields
like Name and State will be null. I want simply to set the foreign id
on the Address object, nothing else.
I believe there is some
good solution for this... my intention is not updating the City object,
and retrieving it to put it back on the address object before being
persisted sounds very strange and a performance nightmare.
What's the proper way to do this?
Thanks!
Note: I'm using application identity and DataNucleus JDO.
____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
> I'm developing a web app, and I'm facing issues with double-proxying... or > so I discovered. My app uses Datanucleus JDO for persistence, and AOP for > transacion definition on business methods. When I included JSecurity code Hi, You've decided to hand off transaction allocation to Spring, hence Spring will handle that. I would have thought that the Spring forums would be a great place to seek help. DataNucleus doesn't seem to be referenced at all, neither in configuration, nor in stack traces, hence nothing I can add. -- Andy Jefferson DataNucleus (http://www.datanucleus.org)
Hi
I'm developing a web app, and I'm facing issues with double-proxying... or so I discovered.
My app uses Datanucleus JDO for persistence, and AOP for transacion definition on business
methods. When I included JSecurity code (I use version 0.9, waiting for Shiro 1.0) from the
sample Spring application (my container is Spring 2.5, and JBoss AS 4.2), my DI of business
beans into other beans no longer worked (trace snippet):
org.springframework.beans.TypeMismatchException:
Failed to convert property value of type [$Proxy61 implementing org.springframework.aop.SpringProxy,org.springframework.aop.framework.Advised,net.sf.cglib.proxy.Factory]
to required type [MYPACKAGE.business.MyBean] for property 'myBean';
Some old post somewhere said about double-proxying, and then I figured it must be the reason,
because of this JSecurity configuration I included:
<!-- Enable JSecurity Annotations for Spring-configured beans. Only run after
the lifecycleBeanProcessor has run: -->
<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"
depends-on="lifecycleBeanPostProcessor" />
I intend to use JSecurity annotation extensively to define security on the business and DAO
layers, but also need definition of transactions for business layer, hopefully through AOP.
How can I solve this conflict?
If helpful, this is my spring metadata for transacion AOP (not quite correct, read-only does
not work, still working on it):
<!-- the transactional advice (what 'happens'; see the <aop:advisor/> bean below)
-->
<tx:advice id="txAdvice" transaction-manager="txManager">
<!-- the transactional semantics... -->
<tx:attributes>
<tx:method name="store*"/>
<tx:method name="update*"/>
<tx:method name="delete*"/>
<tx:method name="*" read-only="true"/>
</tx:attributes>
</tx:advice>
<!-- ensure that the above transactional advice runs for any execution
of an operation defined by the FooService interface -->
<aop:config proxy-target-class="true">
<aop:pointcut id="defaultServiceOperation" expression="execution(* MYPACKAGE.business..*Bean.*(..))"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="defaultServiceOperation"/>
</aop:config>
Many thanks!
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
> I will look at DataNucleus to see if it supports plain simple flat-file DB. I dunno what is "simple flat file DB", and don't really like the idea of inventing our own DB (there must be enough DB's around already :-) ), so if we reuse existing ones there are, at least, * HSQLDB option that David already mentioned, * ODF (the ISO document format used by OpenOffice/KOffice) which is basically XML so is user-editable. * XML itself * JSON - also user-editable These options are all supported by DataNucleus -- Andy (DataNucleus - http://www.datanucleus.org)
Hi Ozvena, I think you'll find that HSQL also store it data in human readable format for some table types. If that satisfies your needs, then DataNucleus will definitely do the job for you as I believe it supports HSQL. Cheers, David ozvena@gmail.com wrote: > Hi Matthew, > > I am not using any flat-file DB. It is a new application I am developing. > The size of the database can range from few entries to few dozen of entries. > Each entry represents 3 strings. I want flat-file DB as it is user readable > and can be changed/edited by hand if needed. > > I will look at DataNucleus to see if it supports plain simple flat-file DB. > > Thank you! > Ozvena > > > > On Tue, May 19, 2009 at 5:04 PM, Matthew Adams <matthew@matthewadams.me>wrote: > >> Hi ozvena, >> >> In order for you to use a flat-file database, you need to find a JDO >> vendor that supports one. First off, what kind of flat-file database >> are you using? I imagine a likely JDO candidate is DataNucleus, the >> JDO reference implementation. If it doesn't support whatever you're >> using for a flat-file database, you can write a plug-in to support it. >> I haven't dug deeply, but you might consider DataNucleus over db4o. >> >> HTH, >> Matthew >> >> On Tue, May 19, 2009 at 2:34 PM, ozvena@gmail.com <ozvena@gmail.com> >> wrote: >>> Hello, >>> >>> I can't find any information about how to configure >>> PersistenceManagerFactory for flat-file database. >>> >>> Your help is appreciated! >>> >> >> >> -- >> mailto:matthew@matthewadams.me >> skype:matthewadams12 >> yahoo:matthewadams >> aol:matthewadams12 >> google-talk:matthewadams12@gmail.com<google-talk%3Amatthewadams12@gmail.com> >> msn:matthew@matthewadams.me >> http://matthewadams.me >> http://www.linkedin.com/in/matthewadams >> >
Hi Matthew, I am not using any flat-file DB. It is a new application I am developing. The size of the database can range from few entries to few dozen of entries. Each entry represents 3 strings. I want flat-file DB as it is user readable and can be changed/edited by hand if needed. I will look at DataNucleus to see if it supports plain simple flat-file DB. Thank you! Ozvena On Tue, May 19, 2009 at 5:04 PM, Matthew Adams <matthew@matthewadams.me>wrote: > Hi ozvena, > > In order for you to use a flat-file database, you need to find a JDO > vendor that supports one. First off, what kind of flat-file database > are you using? I imagine a likely JDO candidate is DataNucleus, the > JDO reference implementation. If it doesn't support whatever you're > using for a flat-file database, you can write a plug-in to support it. > I haven't dug deeply, but you might consider DataNucleus over db4o. > > HTH, > Matthew > > On Tue, May 19, 2009 at 2:34 PM, ozvena@gmail.com <ozvena@gmail.com> > wrote: > > Hello, > > > > I can't find any information about how to configure > > PersistenceManagerFactory for flat-file database. > > > > Your help is appreciated! > > > > > > -- > mailto:matthew@matthewadams.me > skype:matthewadams12 > yahoo:matthewadams > aol:matthewadams12 > google-talk:matthewadams12@gmail.com<google-talk%3Amatthewadams12@gmail.com> > msn:matthew@matthewadams.me > http://matthewadams.me > http://www.linkedin.com/in/matthewadams >
Hi ozvena, In order for you to use a flat-file database, you need to find a JDO vendor that supports one. First off, what kind of flat-file database are you using? I imagine a likely JDO candidate is DataNucleus, the JDO reference implementation. If it doesn't support whatever you're using for a flat-file database, you can write a plug-in to support it. I haven't dug deeply, but you might consider DataNucleus over db4o. HTH, Matthew On Tue, May 19, 2009 at 2:34 PM, ozvena@gmail.com <ozvena@gmail.com> wrote: > Hello, > > I can't find any information about how to configure > PersistenceManagerFactory for flat-file database. > > Your help is appreciated! > -- mailto:matthew@matthewadams.me skype:matthewadams12 yahoo:matthewadams aol:matthewadams12 google-talk:matthewadams12@gmail.com msn:matthew@matthewadams.me http://matthewadams.me http://www.linkedin.com/in/matthewadams
Hello, I can't find any information about how to configure PersistenceManagerFactory for flat-file database. Your help is appreciated!
Thank you, issue is solved. SQLserver's mirroring was responsible for the behavior. Craig L Russell wrote: > > Hi, > > This is probably the wrong forum for this issue. You might try the > datanucleus forum at http://www.jpox.org/servlet/forum/index > > Regards, > > Craig > > On Dec 9, 2008, at 12:11 PM, jamh wrote: > >> >> Hello, >> >> I am running into something quite odd, and wanted to see if anyone >> could >> shed light on this. I have defined two persistence beans as: >> >> <spring:bean id="certPersistFactory" scope="singleton" >> class >> ="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean"> >> <spring:property name="jdoProperties"> >> <spring:props> >> <spring:prop >> key >> = >> "javax >> .jdo >> .PersistenceManagerFactoryClass >> ">org.jpox.jdo.JDOPersistenceManagerFactory >> </spring:prop> >> <spring:prop >> key="javax.jdo.option.ConnectionURL">jdbc:sqlserver:// >> 1.2.3.4:1433;DatabaseName=dbcert;SelectMethod=cursor</spring:prop> >> <spring:prop >> key="javax.jdo.option.ConnectionUserName">user1</spring:prop> >> <spring:prop >> key="javax.jdo.option.ConnectionPassword">passwd1</spring:prop> >> <spring:prop >> key >> = >> "javax >> .jdo >> .option >> .ConnectionDriverName">com.microsoft.sqlserver.jdbc.SQLServerDriver >> </spring:prop> >> <spring:prop >> key="javax.jdo.option.NontransactionalWrite">true</spring:prop> >> <spring:prop >> key="org.jpox.identifier.case">PreserveCase</spring:prop> >> <spring:prop >> key="org.jpox.fixedDatastore">true</spring:prop> >> <spring:prop >> key="org.jpox.validateTables">false</spring:prop> >> </spring:props> >> </spring:property> >> </spring:bean> >> >> <spring:bean id="prodPersistFactory" scope="singleton" >> class >> ="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean"> >> <spring:property name="jdoProperties"> >> <spring:props> >> <spring:prop >> key >> = >> "javax >> .jdo >> .PersistenceManagerFactoryClass >> ">org.jpox.jdo.JDOPersistenceManagerFactory >> </spring:prop> >> <spring:prop >> key="javax.jdo.option.ConnectionURL">jdbc:sqlserver:// >> 1.2.3.4:9546;DatabaseName=dbcert;SelectMethod=cursor</spring:prop> >> <spring:prop >> key="javax.jdo.option.ConnectionUserName">user2</spring:prop> >> <spring:prop >> key="javax.jdo.option.ConnectionPassword">passwd2</spring:prop> >> <spring:prop >> key >> = >> "javax >> .jdo >> .option >> .ConnectionDriverName">com.microsoft.sqlserver.jdbc.SQLServerDriver >> </spring:prop> >> <spring:prop >> key="javax.jdo.option.NontransactionalWrite">true</spring:prop> >> <spring:prop >> key="org.jpox.identifier.case">PreserveCase</spring:prop> >> <spring:prop >> key="org.jpox.fixedDatastore">true</spring:prop> >> <spring:prop >> key="org.jpox.validateTables">false</spring:prop> >> </spring:props> >> </spring:property> >> </spring:bean> >> >> So the first strange thing is that if I reverse their order, ie. if >> I have >> the prod bean precede the cert bean, the app won't start, ie. it >> gives me a >> socket error. >> >> The second strange thing is that with the above, all operations to >> the cert >> bean work flawlessly, but operations to the prod bean give me a >> timeout the >> first time, but then after that, they work ever after. >> >> If I restart the app, again the first operation on the prod bean >> times out, >> and after that it works. >> >> PS: if I have two beans that both run on the same port but different >> hosts, >> everything works fine. The two databases are set up identically. >> >> What is going on? >> Any help is appreciated. >> -- >> View this message in context: >> http://www.nabble.com/Strange-problem%3A-timeout-first-time%2C-then-ok-tp20922247p20922247.html >> Sent from the JDO - Development mailing list archive at Nabble.com. >> > > Craig L Russell > Architect, Sun Java Enterprise System http://db.apache.org/jdo > 408 276-5638 mailto:Craig.Russell@sun.com > P.S. A good JDO? O, Gasp! > > > -- View this message in context: http://www.nabble.com/Re%3A-Strange-problem%3A-timeout-first-time%2C-then-ok-tp20980900p20983445.html Sent from the JDO - User mailing list archive at Nabble.com.
jamh wrote: > > Hello, > > I am running into something quite odd, and wanted to see if anyone could > shed light on this. I have defined two persistence beans as: > [...] > > Issue solved. Sqlserver's mirroring setup was responsible for the strange behavior. -- View this message in context: http://www.nabble.com/Strange-timeout-problem-tp20923897p20983415.html Sent from the JDO - User mailing list archive at Nabble.com.
Hi, This is probably the wrong forum for this issue. You might try the datanucleus forum at http://www.jpox.org/servlet/forum/index Regards, Craig On Dec 9, 2008, at 12:11 PM, jamh wrote: > > Hello, > > I am running into something quite odd, and wanted to see if anyone > could > shed light on this. I have defined two persistence beans as: > > <spring:bean id="certPersistFactory" scope="singleton" > class > ="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean"> > <spring:property name="jdoProperties"> > <spring:props> > <spring:prop > key > = > "javax > .jdo > .PersistenceManagerFactoryClass > ">org.jpox.jdo.JDOPersistenceManagerFactory > </spring:prop> > <spring:prop > key="javax.jdo.option.ConnectionURL">jdbc:sqlserver:// > 1.2.3.4:1433;DatabaseName=dbcert;SelectMethod=cursor</spring:prop> > <spring:prop > key="javax.jdo.option.ConnectionUserName">user1</spring:prop> > <spring:prop > key="javax.jdo.option.ConnectionPassword">passwd1</spring:prop> > <spring:prop > key > = > "javax > .jdo > .option > .ConnectionDriverName">com.microsoft.sqlserver.jdbc.SQLServerDriver > </spring:prop> > <spring:prop > key="javax.jdo.option.NontransactionalWrite">true</spring:prop> > <spring:prop > key="org.jpox.identifier.case">PreserveCase</spring:prop> > <spring:prop > key="org.jpox.fixedDatastore">true</spring:prop> > <spring:prop > key="org.jpox.validateTables">false</spring:prop> > </spring:props> > </spring:property> > </spring:bean> > > <spring:bean id="prodPersistFactory" scope="singleton" > class > ="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean"> > <spring:property name="jdoProperties"> > <spring:props> > <spring:prop > key > = > "javax > .jdo > .PersistenceManagerFactoryClass > ">org.jpox.jdo.JDOPersistenceManagerFactory > </spring:prop> > <spring:prop > key="javax.jdo.option.ConnectionURL">jdbc:sqlserver:// > 1.2.3.4:9546;DatabaseName=dbcert;SelectMethod=cursor</spring:prop> > <spring:prop > key="javax.jdo.option.ConnectionUserName">user2</spring:prop> > <spring:prop > key="javax.jdo.option.ConnectionPassword">passwd2</spring:prop> > <spring:prop > key > = > "javax > .jdo > .option > .ConnectionDriverName">com.microsoft.sqlserver.jdbc.SQLServerDriver > </spring:prop> > <spring:prop > key="javax.jdo.option.NontransactionalWrite">true</spring:prop> > <spring:prop > key="org.jpox.identifier.case">PreserveCase</spring:prop> > <spring:prop > key="org.jpox.fixedDatastore">true</spring:prop> > <spring:prop > key="org.jpox.validateTables">false</spring:prop> > </spring:props> > </spring:property> > </spring:bean> > > So the first strange thing is that if I reverse their order, ie. if > I have > the prod bean precede the cert bean, the app won't start, ie. it > gives me a > socket error. > > The second strange thing is that with the above, all operations to > the cert > bean work flawlessly, but operations to the prod bean give me a > timeout the > first time, but then after that, they work ever after. > > If I restart the app, again the first operation on the prod bean > times out, > and after that it works. > > PS: if I have two beans that both run on the same port but different > hosts, > everything works fine. The two databases are set up identically. > > What is going on? > Any help is appreciated. > -- > View this message in context: http://www.nabble.com/Strange-problem%3A-timeout-first-time%2C-then-ok-tp20922247p20922247.html > Sent from the JDO - Development mailing list archive at Nabble.com. > Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!
Hello,
I am running into something quite odd, and wanted to see if anyone could
shed light on this. I have defined two persistence beans as:
<spring:bean id="certPersistFactory" scope="singleton"
class="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean">
<spring:property name="jdoProperties">
<spring:props>
<spring:prop
key="javax.jdo.PersistenceManagerFactoryClass">org.jpox.jdo.JDOPersistenceManagerFactory
</spring:prop>
<spring:prop
key="javax.jdo.option.ConnectionURL">jdbc:sqlserver://1.2.3.4:1433;DatabaseName=dbcert;SelectMethod=cursor</spring:prop>
<spring:prop
key="javax.jdo.option.ConnectionUserName">user1</spring:prop>
<spring:prop
key="javax.jdo.option.ConnectionPassword">passwd1</spring:prop>
<spring:prop
key="javax.jdo.option.ConnectionDriverName">com.microsoft.sqlserver.jdbc.SQLServerDriver
</spring:prop>
<spring:prop
key="javax.jdo.option.NontransactionalWrite">true</spring:prop>
<spring:prop
key="org.jpox.identifier.case">PreserveCase</spring:prop>
<spring:prop
key="org.jpox.fixedDatastore">true</spring:prop>
<spring:prop
key="org.jpox.validateTables">false</spring:prop>
</spring:props>
</spring:property>
</spring:bean>
<spring:bean id="prodPersistFactory" scope="singleton"
class="org.springframework.orm.jdo.LocalPersistenceManagerFactoryBean">
<spring:property name="jdoProperties">
<spring:props>
<spring:prop
key="javax.jdo.PersistenceManagerFactoryClass">org.jpox.jdo.JDOPersistenceManagerFactory
</spring:prop>
<spring:prop
key="javax.jdo.option.ConnectionURL">jdbc:sqlserver://1.2.3.4:9546;DatabaseName=dbcert;SelectMethod=cursor</spring:prop>
<spring:prop
key="javax.jdo.option.ConnectionUserName">user2</spring:prop>
<spring:prop
key="javax.jdo.option.ConnectionPassword">passwd2</spring:prop>
<spring:prop
key="javax.jdo.option.ConnectionDriverName">com.microsoft.sqlserver.jdbc.SQLServerDriver
</spring:prop>
<spring:prop
key="javax.jdo.option.NontransactionalWrite">true</spring:prop>
<spring:prop
key="org.jpox.identifier.case">PreserveCase</spring:prop>
<spring:prop
key="org.jpox.fixedDatastore">true</spring:prop>
<spring:prop
key="org.jpox.validateTables">false</spring:prop>
</spring:props>
</spring:property>
</spring:bean>
So the first strange thing is that if I reverse their order, ie. if I have
the prod bean precede the cert bean, the app won't start, ie. it gives me a
socket error.
The second strange thing is that with the above, all operations to the cert
bean work flawlessly, but operations to the prod bean give me a timeout the
first time, but then after that, they work ever after.
If I restart the app, again the first operation on the prod bean times out,
and after that it works.
PS: if I have two beans that both run on the same port but different hosts,
everything works fine. The two databases are set up identically.
What is going on?
Any help is appreciated.
--
View this message in context: http://www.nabble.com/Strange-timeout-problem-tp20923897p20923897.html
Sent from the JDO - User mailing list archive at Nabble.com.
I have forgotten to add that I use Kodo 4.1. -tt.
Hi! Suppose I have a Query object q. I execute the query by: q.executeWithArray(params); The execution can take some time... Is there any elegant possibility to stop execution of this query (from another thread, of course) ? -tt.
Hi, > I am using kodo(JDO) for generation of query in our project.How can I > simulate the java code to generate the exists clause in my sql query? > Please throw some light on this. I would have thought that the Oracle forum and support process would the best place to get detailed information about their implementation if you have performance issues with it. Aren't they giving support on Kodo now? Getting an EXISTS clause generated from JDOQL would usually involve the use of the contains() or isEmpty() methods. If you deem that Oracle aren't serious about supporting their JDO implementation then DataNucleus is really what you should be trying, since we do treat JDO as a first class persistence specification ... Regards -- Andy (DataNucleus - http://www.datanucleus.org)
Hi All, I am using kodo(JDO) for generation of query in our project.How can I simulate the java code to generate the exists clause in my sql query? Please throw some light on this. Regards Pandu
Hi,
the use-case sounds very reasonable to me, e.g. when the implementation
of a web-service sends out a serialized persistent object, receives back
the object with changes, and now needs to apply the changes to the
database.
Since makePersistent() is handling attaching so far, this could be the
place to transition such an object from transient to persistent-dirty
(with all fields marked dirty). Maybe an exception should be thrown when
there already is a persistent-dirty object with the same id managed by
the same PM. Since that would mean change of behaviour (somebody might
rely on inserting new objects when calling makePersistent() on transient
instances that have an id value), there probably should be an additional
setMergeOnMakePersistent(boolean) or something like that, defaulting to
the old behaviour.
This would only work for application-identity. For datastore-identity,
some new method(s) would be required to determine the objects' ids, as
Pavel suggested.
Regards,
Jörg
Pavel wrote:
> Hi,
>
> This email is a continuation of discussion started at
> http://www.jpox.org/servlet/forum/viewthread?thread=4893&lastpage=yes .
>
> Quick summary is that there is a number of [I believe fairly strong] cases
> where application deals with transient objects which somehow correspond to
> already persisted objects.
>
> These instances have updated state in there, but persisting that state takes
> extra code and datastore hits, just to preload persistent counterpart and
> copy properties.
>
> My question is whether it is possible and makes sense for JDO to support
> "attachment" of transient objects, so that
> a) all the steps required for such "attachment" become duty of JDO
> implementation, not client code and
> b) reads before update are optimized (e.g. one read for collection) or
> eliminated at all.
>
> Code-wise I imagine methods like
>
> // Application identity
> <T> T attachTransient(T instanceWithAppIdentity);
> <T> Collection<T> attachTransientAll(Collection<T>
> instancesWithAppIdentity);
>
> // Datastore identity - client code provides id explicitly to let JDO
> identify persistent counterpart
> <T> T attachTransient(T instanceWithDSIdentity, Object id);
> <T> Map<Object, T> attachTransientAll(Map<Object, T>
> instancesWithDSIdentity); // Map is {id => instance}
>
> What do you think?
>
> Thanks,
> Pavel
>
>
--
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
UST-Id. DE 217652550
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
FYI, this release fixes manifest file problem.
-- Michelle
-------- Original Message --------
Subject: [VOTE] Release Apache JDO 2.1.1
Date: Sat, 02 Aug 2008 09:41:56 -0700
From: Michelle Caisse <Michelle.Caisse@Sun.COM>
Reply-To: jdo-dev@db.apache.org
To: jdo-dev@db.apache.org, jdo-experts-ext@sun.com
:
This vote is to release the Apache JDO 2.1.1 TCK and API (both legacy
and current versions) with the projects that they depend on: enhancer,
model, and util.
[+1] Release JDO 2.1.1 api, tck, enhancer, model, and util
[0] Don't care
[-1] Don't release JDO 2.1.1 api, tck, enhancer, model, and util because:
The TCK can be tested from the staging area,
http://people.apache.org/~mcaisse/jdo2.1.1/dist. Please follow the
directions at http://wiki.apache.org/jdo/ReleaseTesting2dot1dot1 for
downloading and testing.
JDO 2.1.1 provides fixes for the following issues:
*
http://issues.apache.org/jira/browse/JDO-584
*
http://issues.apache.org/jira/browse/JDO-585
*
http://issues.apache.org/jira/browse/JDO-586
*
http://issues.apache.org/jira/browse/JDO-593
*
http://issues.apache.org/jira/browse/JDO-600
*
http://issues.apache.org/jira/browse/JDO-601
Please test and vote. Voting will close at noon PDT Tuesday, August 5.
-- Michelle
We can get a fix out pretty quickly. To be able to track the issue can you file a JDO JIRA? http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10630 Thanks, Craig On Jul 23, 2008, at 4:37 PM, Raymond Lai wrote: > > Hi there, > > As per discussion on > > http://www.nabble.com/Is-it-a-bug--Felix-cannot-parse-Bundle-ManifestVersion-having-trailing-spaces-td18613664.html#a18617865 > > While they had committed a fix to Felix, the people there suggests > it's also > the problem of the JDO2 API's jar file - more specifially, is this > line: > > Bundle-ManifestVersion: 2 > > The trailing space after 2 was causing the problem that made JDO2 > API cannot > be started on Apache Felix as an OSGi bundle. > > Would the people working on the JDO spec fix this line? > > TIA, > Raymond > -- > View this message in context: http://www.nabble.com/JDO2-API%27s-manifest-file-problem-with-Apache-Felix-tp18622812p18622812.html > Sent from the JDO - User mailing list archive at Nabble.com. > Craig L 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!
Yes, I agree that it should be removed. -- Michelle Andy Jefferson wrote: >To Craig et al, > >why does jdo2.jar include the file "API2.MF" ? Yes this file should be put >into the jar as the MANIFEST.MF but *not* also included in its own right. >There's a block in project.xml that includes it - I suggest that needs >removing. > > > >
To Craig et al, why does jdo2.jar include the file "API2.MF" ? Yes this file should be put into the jar as the MANIFEST.MF but *not* also included in its own right. There's a block in project.xml that includes it - I suggest that needs removing. -- Andy (DataNucleus - http://www.datanucleus.org)
> The trailing space after 2 was causing the problem that made JDO2 API > cannot be started on Apache Felix as an OSGi bundle. > > Would the people working on the JDO spec fix this line? The code in SVN no longer has a trailing space for the MANIFEST, nor for the other lines. Someone must have been using a Windows editor or something ;-) This will affect JDO2.2 onwards. Regards -- Andy (DataNucleus - http://www.datanucleus.org)
I've added an issue to include 2.1, thanks Raymond. Perhaps the JDO team will fix the issue before we get it done on our end, but either way it will be good to have it there. Feel free to add yourself as a watcher to this issue: https://issuetracker.springsource.com/browse/BRITS-119 - Chris On Jul 23, 2008, at 8:00 PM, Raymond Lai wrote: > > But unfortunately, I'm also using JDO 2.1 annotations which is > available only > from JDO 2.1 API. So... no go. :-( > > Thanks for your kind help anyway, > Raymond > > > cbeams wrote: >> >> Raymond, >> >> In the meantime, consider using the bundle we've packaged within the >> SpringSource Enterprise Bundle Repository. That manifest should be >> OK. >> >> http://springsource.com/repository/app/bundle/version/detail?name=com.springsource.javax.jdo&version=2.0.0 >> >> - Chris >> >> Chris Beams >> Sr. Consultant, SpringSource >> http://springsource.com >> >> >> On Jul 23, 2008, at 4:37 PM, Raymond Lai wrote: >> >>> >>> Hi there, >>> >>> As per discussion on >>> >>> http://www.nabble.com/Is-it-a-bug--Felix-cannot-parse-Bundle-ManifestVersion-having-trailing-spaces-td18613664.html#a18617865 >>> >>> While they had committed a fix to Felix, the people there suggests >>> it's also >>> the problem of the JDO2 API's jar file - more specifially, is this >>> line: >>> >>> Bundle-ManifestVersion: 2 >>> >>> The trailing space after 2 was causing the problem that made JDO2 >>> API cannot >>> be started on Apache Felix as an OSGi bundle. >>> >>> Would the people working on the JDO spec fix this line? >>> >>> TIA, >>> Raymond >>> -- >>> View this message in context: >>> http://www.nabble.com/JDO2-API%27s-manifest-file-problem-with-Apache-Felix-tp18622812p18622812.html >>> Sent from the JDO - User mailing list archive at Nabble.com. >>> >> >> >> > > -- > View this message in context: http://www.nabble.com/JDO2-API%27s-manifest-file-problem-with-Apache-Felix-tp18622812p18624618.html > Sent from the JDO - User mailing list archive at Nabble.com. >
But unfortunately, I'm also using JDO 2.1 annotations which is available only from JDO 2.1 API. So... no go. :-( Thanks for your kind help anyway, Raymond cbeams wrote: > > Raymond, > > In the meantime, consider using the bundle we've packaged within the > SpringSource Enterprise Bundle Repository. That manifest should be OK. > > http://springsource.com/repository/app/bundle/version/detail?name=com.springsource.javax.jdo&version=2.0.0 > > - Chris > > Chris Beams > Sr. Consultant, SpringSource > http://springsource.com > > > On Jul 23, 2008, at 4:37 PM, Raymond Lai wrote: > >> >> Hi there, >> >> As per discussion on >> >> http://www.nabble.com/Is-it-a-bug--Felix-cannot-parse-Bundle-ManifestVersion-having-trailing-spaces-td18613664.html#a18617865 >> >> While they had committed a fix to Felix, the people there suggests >> it's also >> the problem of the JDO2 API's jar file - more specifially, is this >> line: >> >> Bundle-ManifestVersion: 2 >> >> The trailing space after 2 was causing the problem that made JDO2 >> API cannot >> be started on Apache Felix as an OSGi bundle. >> >> Would the people working on the JDO spec fix this line? >> >> TIA, >> Raymond >> -- >> View this message in context: >> http://www.nabble.com/JDO2-API%27s-manifest-file-problem-with-Apache-Felix-tp18622812p18622812.html >> Sent from the JDO - User mailing list archive at Nabble.com. >> > > > -- View this message in context: http://www.nabble.com/JDO2-API%27s-manifest-file-problem-with-Apache-Felix-tp18622812p18624618.html Sent from the JDO - User mailing list archive at Nabble.com.
I noticed that the jdo2 api jar isn't recognized in Eclipse v3.4 (Ganymeede) while it is in v3.3. My guess is that it's the same issue. Scott -----Original Message----- From: Raymond Lai [mailto:airwave209gt@gmail.com] Sent: Wednesday, July 23, 2008 6:38 PM To: jdo-user@db.apache.org Subject: JDO2 API's manifest file problem with Apache Felix Hi there, As per discussion on http://www.nabble.com/Is-it-a-bug--Felix-cannot-parse-Bundle-ManifestVer sion-having-trailing-spaces-td18613664.html#a18617865 While they had committed a fix to Felix, the people there suggests it's also the problem of the JDO2 API's jar file - more specifially, is this line: Bundle-ManifestVersion: 2 The trailing space after 2 was causing the problem that made JDO2 API cannot be started on Apache Felix as an OSGi bundle. Would the people working on the JDO spec fix this line? TIA, Raymond -- View this message in context: http://www.nabble.com/JDO2-API%27s-manifest-file-problem-with-Apache-Fel ix-tp18622812p18622812.html Sent from the JDO - User mailing list archive at Nabble.com.
Raymond, In the meantime, consider using the bundle we've packaged within the SpringSource Enterprise Bundle Repository. That manifest should be OK. http://springsource.com/repository/app/bundle/version/detail?name=com.springsource.javax.jdo&version=2.0.0 - Chris Chris Beams Sr. Consultant, SpringSource http://springsource.com On Jul 23, 2008, at 4:37 PM, Raymond Lai wrote: > > Hi there, > > As per discussion on > > http://www.nabble.com/Is-it-a-bug--Felix-cannot-parse-Bundle-ManifestVersion-having-trailing-spaces-td18613664.html#a18617865 > > While they had committed a fix to Felix, the people there suggests > it's also > the problem of the JDO2 API's jar file - more specifially, is this > line: > > Bundle-ManifestVersion: 2 > > The trailing space after 2 was causing the problem that made JDO2 > API cannot > be started on Apache Felix as an OSGi bundle. > > Would the people working on the JDO spec fix this line? > > TIA, > Raymond > -- > View this message in context: http://www.nabble.com/JDO2-API%27s-manifest-file-problem-with-Apache-Felix-tp18622812p18622812.html > Sent from the JDO - User mailing list archive at Nabble.com. >
Hi there, As per discussion on http://www.nabble.com/Is-it-a-bug--Felix-cannot-parse-Bundle-ManifestVersion-having-trailing-spaces-td18613664.html#a18617865 While they had committed a fix to Felix, the people there suggests it's also the problem of the JDO2 API's jar file - more specifially, is this line: Bundle-ManifestVersion: 2 The trailing space after 2 was causing the problem that made JDO2 API cannot be started on Apache Felix as an OSGi bundle. Would the people working on the JDO spec fix this line? TIA, Raymond -- View this message in context: http://www.nabble.com/JDO2-API%27s-manifest-file-problem-with-Apache-Felix-tp18622812p18622812.html Sent from the JDO - User mailing list archive at Nabble.com.
Hi,
This email is a continuation of discussion started at
http://www.jpox.org/servlet/forum/viewthread?thread=4893&lastpage=yes .
Quick summary is that there is a number of [I believe fairly strong] cases
where application deals with transient objects which somehow correspond to
already persisted objects.
These instances have updated state in there, but persisting that state takes
extra code and datastore hits, just to preload persistent counterpart and
copy properties.
My question is whether it is possible and makes sense for JDO to support
"attachment" of transient objects, so that
a) all the steps required for such "attachment" become duty of JDO
implementation, not client code and
b) reads before update are optimized (e.g. one read for collection) or
eliminated at all.
Code-wise I imagine methods like
// Application identity
<T> T attachTransient(T instanceWithAppIdentity);
<T> Collection<T> attachTransientAll(Collection<T>
instancesWithAppIdentity);
// Datastore identity - client code provides id explicitly to let JDO
identify persistent counterpart
<T> T attachTransient(T instanceWithDSIdentity, Object id);
<T> Map<Object, T> attachTransientAll(Map<Object, T>
instancesWithDSIdentity); // Map is {id => instance}
What do you think?
Thanks,
Pavel
Hi Soham, What implementation of jdo are you using? Sounds like a bug in the interaction of your application and the environment (Spring and ???). Craig On May 1, 2008, at 11:22 PM, Soham Ghosh wrote: > Hi, > I have the following problem: > Thread T1 is interrupted so its interrupted flag is set to true. > After that, > it tries to create some record in the db using spring and jdo. After > the > records are committed, the thread's interrupted flag is reset to > false. Any > idea why? > > Thanks > Soham 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!
Hi Daniel, This is easy to add. Could you file a JIRA? http://issues.apache.org/jira/secure/BrowseProject.jspa Thanks, Michelle Daniel L Leary wrote: > Is there any reason that JDO annotations aren't marked @Documented? > > -Dan
Hi, I have the following problem: Thread T1 is interrupted so its interrupted flag is set to true. After that, it tries to create some record in the db using spring and jdo. After the records are committed, the thread's interrupted flag is reset to false. Any idea why? Thanks Soham
Is there any reason that JDO annotations aren't marked @Documented? -Dan
Hi Markus, I believe that I have fixed the problem with release-2.1.cgi, though it may take a few hours to reach the external site. The spec is actually not there. The official 2.1 spec will be available from http://jcp.org/en/jsr/detail?id=243 in a few days. Currently, you can download the final draft at http://db.apache.org/jdo/specifications.html. There are no changes from that version to the one that will be on the JCP site. I don't have any trouble with the ibiblio link to jdo2-api-2.0.jar. I can also get the 2.1 jar by just changing that URL from...2.0.jar to 2.1.jar. Maybe there was a temporary problem at ibiblio. You can get all the jar files by browsing http://www.ibiblio.org/maven/javax.jdo/jars/ and http://www.ibiblio.org/maven/org.apache.jdo/jars/. And the final 2.1 javadoc is at the Apache JDO site: http://db.apache.org/jdo/javadoc.html. Hope this helps, Michelle Markus.Bach@hydrometer.de wrote: >Hi. > >I tried to download the latest version of the JDO 2.1 spec from the >downloads page of db.apache.org. >But everytime I click on the link >http://db.apache.org/jdo/releases/release-2.1.cgi I get an "Internal Server >Error". >If I try to download JDO 2.0 I can see the next page with the download >links for all the JDO >parts, but then the link >http://www.ibiblio.org/maven/javax.jdo/jars/jdo2-api-2.0.jar gives me an >"Internal Server Error" too. > >Please, can some fix the links for downloading? > >Thanks > >Markus >_____________________________________________________________________________________ > >Bitte überlegen Sie, ob Sie diese Nachricht wirklich ausdrucken müssen/ >before printing, think about environmental responsibility. > >Hydrometer GmbH, Industriestraße 13, 91522 Ansbach, >Telefon + 49 981 1806 0, Telefax +49 981 1806 615 >Sitz der Gesellschaft: Ansbach, Registriergericht: Ansbach HRB 69 >Geschäftsführer: Johannes Sappa (Sprecher), Dr.-Ing. Robert Westphal > >Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese >E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. >Informieren Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise >erhalten haben. Bitte löschen Sie in diesem Fall die Nachricht. Jede >unerlaubte Form der Reproduktion, Bekanntgabe, Änderung, Verteilung >und/oder Publikation dieser E-Mail ist strengstens untersagt. > >The contents of the above mentioned e-mail is not legally binding. This >e-mail contains confidential and/or legally protected information. Please >inform us if you have received this e-mail by mistake and delete it in such >a case. Each unauthorized reproduction, disclosure, alteration, >distribution and/or publication of this e-mail is strictly prohibited. > > >
Hi. I tried to download the latest version of the JDO 2.1 spec from the downloads page of db.apache.org. But everytime I click on the link http://db.apache.org/jdo/releases/release-2.1.cgi I get an "Internal Server Error". If I try to download JDO 2.0 I can see the next page with the download links for all the JDO parts, but then the link http://www.ibiblio.org/maven/javax.jdo/jars/jdo2-api-2.0.jar gives me an "Internal Server Error" too. Please, can some fix the links for downloading? Thanks Markus _____________________________________________________________________________________ Bitte überlegen Sie, ob Sie diese Nachricht wirklich ausdrucken müssen/ before printing, think about environmental responsibility. Hydrometer GmbH, Industriestraße 13, 91522 Ansbach, Telefon + 49 981 1806 0, Telefax +49 981 1806 615 Sitz der Gesellschaft: Ansbach, Registriergericht: Ansbach HRB 69 Geschäftsführer: Johannes Sappa (Sprecher), Dr.-Ing. Robert Westphal Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Informieren Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise erhalten haben. Bitte löschen Sie in diesem Fall die Nachricht. Jede unerlaubte Form der Reproduktion, Bekanntgabe, Änderung, Verteilung und/oder Publikation dieser E-Mail ist strengstens untersagt. The contents of the above mentioned e-mail is not legally binding. This e-mail contains confidential and/or legally protected information. Please inform us if you have received this e-mail by mistake and delete it in such a case. Each unauthorized reproduction, disclosure, alteration, distribution and/or publication of this e-mail is strictly prohibited.
Hi, Kodo (a commercial solution) offers a tool with three types of mapping: forward, reverse (database to class) and meet-in-the-middle. See http://edocs.bea.com/kodo/docs41/full/html/ref_guide_mapping.html kind regards, Christiaan -- View this message in context: http://www.nabble.com/O-RM-mapping-tp14802967p14837564.html Sent from the JDO - User mailing list archive at Nabble.com.