dev@cayenne.apache.org Archives

SQLTemplate for not object queries and NullPointerException

2009-12-07T10:52:15Z

Today I tried to use SQLTemplate for not object query (expecting to
get list of DataRows).

Here is what I did:

    public void testSQLTemplateForDataMapWithInsert() {
        DataMap testDataMap = context.getEntityResolver().getDataMap("testmap");
        String sql = "INSERT INTO ARTIST VALUES (15, 'Surikov', null)";
        SQLTemplate q1 = new SQLTemplate(testDataMap, sql);
        context.performNonSelectingQuery(q1);

        SQLTemplate q2 = new SQLTemplate(testDataMap, "SELECT * FROM ARTIST");
        List result = context.performQuery(q2);
        assertEquals(1, result.size());
    }

I got :

java.lang.NullPointerException
	at org.apache.cayenne.access.ObjectResolver.(ObjectResolver.java:60)
	at org.apache.cayenne.access.DataDomainQueryAction$ObjectConversionStrategy.toObjects(DataDomainQueryAction.java:568)
	at org.apache.cayenne.access.DataDomainQueryAction$SingleObjectConversionStrategy.convert(DataDomainQueryAction.java:603)
	at org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConversion(DataDomainQueryAction.java:451)
	at org.apache.cayenne.access.DataDomainQueryAction.execute(DataDomainQueryAction.java:125)
	at org.apache.cayenne.access.UnitTestDomainQueryAction.execute(UnitTestDomainQueryAction.java:48)
	at org.apache.cayenne.access.UnitTestDomain.onQuery(UnitTestDomain.java:63)
	at org.apache.cayenne.util.ObjectContextQueryAction.runQuery(ObjectContextQueryAction.java:335)
	at org.apache.cayenne.util.ObjectContextQueryAction.execute(ObjectContextQueryAction.java:96)
	at org.apache.cayenne.access.DataContext.onQuery(DataContext.java:1049)
	at org.apache.cayenne.access.DataContext.performQuery(DataContext.java:1038)
	at org.apache.cayenne.query.SQLTemplateTest.testSQLTemplateForDataMapWithInsert(SQLTemplateTest.java:64)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)


Going to create JIRA issue for it...

Evgeny.

Re: DI-based configuration works

2009-12-06T23:26:52Z

Forgot one more important new feature:

* Any Cayenne extensions provided by users in the XML (custom  
DbAdapters, DataSourceFactories, etc) are passed through an injector  
on creation, so they don't have to rely on app-specific kludges to  
obtain various environment services (e.g. ResourceLocator). So you can  
do something like this:

class MyDataSourceFactory implements DataSourceFactory {

   @Inject
   private ResourceLocator resourceLocator;

   @Inject
   private SomeofMyOnwServices service1;

   ...
}

Andrus

On Dec 6, 2009, at 6:20 PM, Andrus Adamchik wrote:

> An update on the new DI configuration... The new DI stack is now  
> usable as a fully functional alternative to Configuration. I created  
> an integration test module [1], showing how Cayenne can be started  
> using the new approach. Actually it is as simple as that:
>
> CayenneServerRuntime runtime = new CayenneServerRuntime(name.name());
> ObjectContext context = runtime.newContext();
>
> BTW "Server" in runtime name implies that we should be able to build  
> a "Client" runtime for ROP stack in the future (actually should be  
> quite easy). Configuration is done in a DI "module" class. Here is a  
> standard one that can be amended or partially overridden by the  
> users - [2]. Some highlights:
>
> * The new configuration provides all the same functionality as the  
> old one (except for JNDI preferences hack, which will turn into a  
> first class feature once CAY-1327 is implemented).
>
> * The new configuration is using a single-domain format compatible  
> with CAY-1318.
>
> * The new configuration loads descriptors from uniquely named files,  
> such as "cayenne-stackname.xml, so there's no more single  
> cayenne.xml file, and less chance of odd naming conflicts between  
> multiple jars.
>
> * Rewrote a bunch of old configuration code, which is now so much  
> cleaner, mainly due to the design with injection in mind. There are  
> still some rough spots in the service definitions and some functions  
> missing in DI that I'd like to have, but it fully works as is.
>
> * Better project model representation. I finally separated  
> configuration objects (DataDomainDescriptor, DataNodeDescriptor)  
> from runtime objects (DataDomain, DataNode). This made the runtime  
> code cleaner, and also opens possibilities for cleaner Modeler code  
> (currently there are lots of hacks to "edit" runtime objects).
>
> * Added a number of important pluggable abstractions [2], such as  
> ResourceLocator.
>
> * Performance... I didn't see any difference in application startup  
> time on a simple app between the new and the old stack.
>
> So the next step is to finish CAY-1318 (which is mainly about  
> upgrading the old projects to the new format), and to do the switch  
> to the new configuration. In terms of public API, I think that most  
> of the classes in org.apache.cayenne.conf will have to go. There's  
> no point in deprecating them (although I sort of did it in a few  
> places already), as the framework will not use them at all. One  
> possible interim step is moving all these classes from runtime jars  
> to the Modeler, so that the Modeler could read older project files  
> and perform needed upgrades. At a later point we may also refactor  
> the Modeler to use the new configuration classes, as mentioned above.
>
> Also there's more work to be done to align the new config with the  
> current config expectations (such as a singleton configuration...  
> what do you think, do we need to keep it?? , provide an analog of  
> FileConfiguration, etc.)
>
> Andrus
>
>
> [1] http://fisheye6.atlassian.com/browse/cayenne/trunk/itests/cayenne-di-stack
>
> [2] http://fisheye6.atlassian.com/browse/cayenne/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/configuration/CayenneServerModule.java?r=HEAD&content=true
>
>

DI-based configuration works

2009-12-06T23:20:37Z

An update on the new DI configuration... The new DI stack is now
usable as a fully functional alternative to Configuration. I created
an integration test module [1], showing how Cayenne can be started
using the new approach. Actually it is as simple as that:

CayenneServerRuntime runtime = new CayenneServerRuntime(name.name());
ObjectContext context = runtime.newContext();

BTW "Server" in runtime name implies that we should be able to build a
"Client" runtime for ROP stack in the future (actually should be quite
easy). Configuration is done in a DI "module" class. Here is a
standard one that can be amended or partially overridden by the users
- [2]. Some highlights:

* The new configuration provides all the same functionality as the old
one (except for JNDI preferences hack, which will turn into a first
class feature once CAY-1327 is implemented).

* The new configuration is using a single-domain format compatible
with CAY-1318.

* The new configuration loads descriptors from uniquely named files,
such as "cayenne-stackname.xml, so there's no more single cayenne.xml
file, and less chance of odd naming conflicts between multiple jars.

* Rewrote a bunch of old configuration code, which is now so much
cleaner, mainly due to the design with injection in mind. There are
still some rough spots in the service definitions and some functions
missing in DI that I'd like to have, but it fully works as is.

* Better project model representation. I finally separated
configuration objects (DataDomainDescriptor, DataNodeDescriptor) from
runtime objects (DataDomain, DataNode). This made the runtime code
cleaner, and also opens possibilities for cleaner Modeler code
(currently there are lots of hacks to "edit" runtime objects).

* Added a number of important pluggable abstractions [2], such as
ResourceLocator.

* Performance... I didn't see any difference in application startup
time on a simple app between the new and the old stack.

So the next step is to finish CAY-1318 (which is mainly about
upgrading the old projects to the new format), and to do the switch to
the new configuration. In terms of public API, I think that most of
the classes in org.apache.cayenne.conf will have to go. There's no
point in deprecating them (although I sort of did it in a few places
already), as the framework will not use them at all. One possible
interim step is moving all these classes from runtime jars to the
Modeler, so that the Modeler could read older project files and
perform needed upgrades. At a later point we may also refactor the
Modeler to use the new configuration classes, as mentioned above.

Also there's more work to be done to align the new config with the
current config expectations (such as a singleton configuration... what
do you think, do we need to keep it?? , provide an analog of
FileConfiguration, etc.)

Andrus

[1] http://fisheye6.atlassian.com/browse/cayenne/trunk/itests/cayenne-di-stack

[2] http://fisheye6.atlassian.com/browse/cayenne/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/configuration/CayenneServerModule.java?r=HEAD&content=true

Re: Tutorials

2009-12-04T16:08:04Z

Yeah, I am using pretty much the same thing locally. Good idea t check  
whether embedded Jetty is usable as a web container. (I thought  
Eclipse uses it for something other than web apps execution?)

Andrus

On Dec 4, 2009, at 5:48 PM, Mike Kienenberger wrote:

> For an Eclipse WebContainer, I use an external jetty install (although
> I think Jetty 7 now ships with Eclipse), a jetty-xml config file, and
> a file-based (Run Config -> Common -> Save as local file) run
> configuration specifying the main class and any other configuration.
> Turned out to be a lot easier than trying to keep up with
> JettyLauncher, and gave me more options.   I can check both
> configurations into the project, and by defining a jetty user library
> (pointing to the jetty install libs), all of the other team members
> can use it.   They grab the jetty version of their choice, add it to
> to their user lib, and it all just works.
>
> For eclipse-based tutorials, this would all be straight-forward except
> for the external jetty install, but if newer versions of eclipse ship
> with jetty bundled, then that problem goes away.
>
> It's generally useful info, so I sanitized my config files and
> attached them to the message as well as included them inline as text.
>
> =====================Jetty projectname.launch ====================
>
> 
>  type="org.eclipse.jdt.launching.localJavaApplication">
>  value="jetty-run-configuration.eclipse"/>
> 
> 
> 
> 
> 
> 
>  value="org.mortbay.start.Main"/>
>  value="jetty-projectName.xml"/>
>  value="projectName"/>
>  value="-XX:MaxPermSize=256m
> -Djetty.keystore.home=${workspace_loc:projectName}
> -Djetty.webappRootDir=${workspace_loc:projectName}"/>
> 
>
> ===================== ^^^^^^^^^^^^^^^^^^^^^^^^^^^^  
> ====================
>
> =====================Jetty projectname.xml ====================
>
> 
>  "http://jetty.mortbay.org/configure.dtd">
> 
>    
>      
>        2
>        2
>        10
>      
>    
>
> 	
> 	    
> 	      
> 	        4443
> 	        30000
> 	         name="jetty.keystore.home" default="." />/keystore-jetty
> 	        password
> 	        keyPassword
> 	         name="jetty.keystore.home" default="." />/keystore-jetty
> 	        trustPassword
> 	      
> 	    
> 	  
>
>    
>      
>          
>             default="7777"/>
>            30000
>            2
>            4443
>          
>      
>    
>    
>       class="org.mortbay.jetty.handler.HandlerCollection">
>        
>         
>           
>              class="org.mortbay.jetty.handler.ContextHandlerCollection"/>
>           
>           
>              class="org.mortbay.jetty.handler.DefaultHandler"/>
>           
>           
>              class="org.mortbay.jetty.handler.RequestLogHandler"/>
>           
>         
>        
>      
>    
>     class="org.mortbay.jetty.webapp.WebAppContext">
>      
>       Arg>
>      /projectName
>    
>
>    
>    
>    
>    true
>    
>    true
>
> 	
> 
> 	
> 
> ===================== ^^^^^^^^^^^^^^^^^^^^^^^^^^^^  
> ====================
>
>
> On Fri, Dec 4, 2009 at 4:13 AM, Andrus Adamchik  > wrote:
>> I think I am giving up on an idea of a Maven-free tutorial. It will  
>> be just
>> too hard for us to maintain... In return for introducing Maven to the
>> "Getting Started" tutorials we'll get a these benefits:
>>
>> * Maven-based web container start (I am at a loss which webapp  
>> Eclipse
>> plugin to recommend to users these days... They either suck or  
>> unsupported
>> and out of date... I am personally using a Jetty launcher with main  
>> class
>> that I wrote).
>>
>> * Declarative dependency management (instead of "download Derby  
>> from here",
>> we just tell them to place it in the pom).
>>
>> * Tutorials code can be built together with Cayenne core, so they  
>> never
>> become invalid (and there's a better chance they will be  
>> maintained), and
>> also can be easily bundled with a release.
>>
>>
>> The downsides are:
>>
>> * Some people just won't bother using Maven
>>
>> * Since dependency management is transparent, we don't show how to  
>> include
>> dependent jars in the project.
>>
>> I guess Maven wins...
>>
>> Andrus
>>
>

Re: Tutorials

2009-12-04T15:48:28Z

For an Eclipse WebContainer, I use an external jetty install (although
I think Jetty 7 now ships with Eclipse), a jetty-xml config file, and
a file-based (Run Config -> Common -> Save as local file) run
configuration specifying the main class and any other configuration.
Turned out to be a lot easier than trying to keep up with
JettyLauncher, and gave me more options.   I can check both
configurations into the project, and by defining a jetty user library
(pointing to the jetty install libs), all of the other team members
can use it.   They grab the jetty version of their choice, add it to
to their user lib, and it all just works.

For eclipse-based tutorials, this would all be straight-forward except
for the external jetty install, but if newer versions of eclipse ship
with jetty bundled, then that problem goes away.

It's generally useful info, so I sanitized my config files and
attached them to the message as well as included them inline as text.

=====================Jetty projectname.launch ====================

===================== ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ====================

=====================Jetty projectname.xml ====================

        2
        2
        10

	        4443
	        30000
	        /keystore-jetty
	        password
	        keyPassword
	        /keystore-jetty
	        trustPassword

            30000
            2
            4443

      /projectName

    true

    true

===================== ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ====================

On Fri, Dec 4, 2009 at 4:13 AM, Andrus Adamchik  wrote:
> I think I am giving up on an idea of a Maven-free tutorial. It will be just
> too hard for us to maintain... In return for introducing Maven to the
> "Getting Started" tutorials we'll get a these benefits:
>
> * Maven-based web container start (I am at a loss which webapp Eclipse
> plugin to recommend to users these days... They either suck or unsupported
> and out of date... I am personally using a Jetty launcher with main class
> that I wrote).
>
> * Declarative dependency management (instead of "download Derby from here",
> we just tell them to place it in the pom).
>
> * Tutorials code can be built together with Cayenne core, so they never
> become invalid (and there's a better chance they will be maintained), and
> also can be easily bundled with a release.
>
>
> The downsides are:
>
> * Some people just won't bother using Maven
>
> * Since dependency management is transparent, we don't show how to include
> dependent jars in the project.
>
> I guess Maven wins...
>
> Andrus
>

RE: Tutorials

2009-12-04T10:47:15Z



> * Tutorials code can be built together with Cayenne core, so they  
> never become invalid (and there's a better chance they will be  
> maintained), and also can be easily bundled with a release.

Some note from my experience.
Best way is to add tutorials build and any docs build as a profile in Maven (turned off by
default). And turn on this profile at Hudson. Also turn it while release. If someone changing
docs he should turn it.
But nobody else want to build docs every time.

Evgeny.

Tutorials

2009-12-04T09:13:13Z

I think I am giving up on an idea of a Maven-free tutorial. It will be  
just too hard for us to maintain... In return for introducing Maven to  
the "Getting Started" tutorials we'll get a these benefits:

* Maven-based web container start (I am at a loss which webapp Eclipse  
plugin to recommend to users these days... They either suck or  
unsupported and out of date... I am personally using a Jetty launcher  
with main class that I wrote).

* Declarative dependency management (instead of "download Derby from  
here", we just tell them to place it in the pom).

* Tutorials code can be built together with Cayenne core, so they  
never become invalid (and there's a better chance they will be  
maintained), and also can be easily bundled with a release.


The downsides are:

* Some people just won't bother using Maven

* Since dependency management is transparent, we don't show how to  
include dependent jars in the project.

I guess Maven wins...

Andrus

=?UTF-8?Q?Hudson_build_is_back_to_normal:_Cay?= =?UTF-8?Q?enne-trunk_=C2=BB_JDK_1.6_(latest),h2_#72?=

2009-12-03T19:55:30Z

See

=?UTF-8?Q?Build_failed_in_Hudson:_Cayenne?= =?UTF-8?Q?-trunk_=C2=BB_JDK_1.6_(latest),h2_#71?=

2009-12-03T15:06:33Z

See 

Changes:

[oltka] * add note to RELEASE-NOTES adout CAY-1314

[andrey] CAY-762 ERDiagram for Object Entities in Cayenne Modeler. Show on Graph buttons for
entities

------------------------------------------
[...truncated 70623 lines...]
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1786, 2->ID_CLOB:265, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1787, 2->ID_CLOB:235, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1788, 2->ID_CLOB:279, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1789, 2->ID_CLOB:293, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1790, 2->ID_CLOB:296, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1791, 2->ID_CLOB:221, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1792, 2->ID_CLOB:253, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1793, 2->ID_CLOB:248, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1794, 2->ID_CLOB:222, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1795, 2->ID_CLOB:284, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1796, 2->ID_CLOB:244, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1797, 2->ID_CLOB:283, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1798, 2->ID_CLOB:287, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ID:1799, 2->ID_CLOB:257, 3->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 1 query.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: SELECT t0.CLOB_TEST_ID, t0.CLOB_COL FROM CLOB_TEST t0 JOIN CLOB_TEST_RELATION t1 ON
(t0.CLOB_TEST_ID = t1.ID_CLOB) WHERE t1.VALUE = ? [bind: 1->VALUE:100]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logSelectCount
INFO: === returned 25 rows. - took 6 ms.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.363 sec
Running org.apache.cayenne.access.DataContextQueryCachingTest
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 2 queries.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: insert into ARTIST (ARTIST_ID, ARTIST_NAME) values (33001, 'aaa')
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: INSERT INTO PAINTING (PAINTING_ID, PAINTING_TITLE, ARTIST_ID, ESTIMATED_PRICE) VALUES
(33001, 'P', 33001, 4000)
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 1 query.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: SELECT t0.DATE_OF_BIRTH, t0.ARTIST_ID, t0.ARTIST_NAME FROM ARTIST t0
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logSelectCount
INFO: === returned 1 row. - took 0 ms.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 1 query.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: update ARTIST set ARTIST_NAME = 'bbb' where ARTIST_ID = 33001
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 1 query.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: SELECT t0.DATE_OF_BIRTH, t0.ARTIST_ID, t0.ARTIST_NAME FROM ARTIST t0
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logSelectCount
INFO: === returned 1 row. - took 1 ms.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.cayenne.access.NestedDataContextParentPeerEventsTest
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 1 query.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: INSERT INTO ARTIST (ARTIST_ID, ARTIST_NAME, DATE_OF_BIRTH) VALUES (?, ?, ?)
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ARTIST_ID:256, 2->ARTIST_NAME:'X', 3->DATE_OF_BIRTH:NULL]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 1 query.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: UPDATE ARTIST SET ARTIST_NAME = ? WHERE ARTIST_ID = ?
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ARTIST_NAME:'Y', 2->ARTIST_ID:256]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 2 queries.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: INSERT INTO ARTIST (ARTIST_ID, ARTIST_NAME, DATE_OF_BIRTH) VALUES (?, ?, ?)
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ARTIST_ID:257, 2->ARTIST_NAME:'X', 3->DATE_OF_BIRTH:NULL]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ARTIST_ID:258, 2->ARTIST_NAME:'Y', 3->DATE_OF_BIRTH:NULL]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: INSERT INTO PAINTING (ARTIST_ID, ESTIMATED_PRICE, GALLERY_ID, PAINTING_DESCRIPTION,
PAINTING_ID, PAINTING_TITLE) VALUES (?, ?, ?, ?, ?, ?)
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ARTIST_ID:257, 2->ESTIMATED_PRICE:NULL, 3->GALLERY_ID:NULL, 4->PAINTING_DESCRIPTION:NULL,
5->PAINTING_ID:256, 6->PAINTING_TITLE:'PPP']
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 1 query.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: UPDATE PAINTING SET ARTIST_ID = ? WHERE PAINTING_ID = ?
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ARTIST_ID:258, 2->PAINTING_ID:256]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 2 queries.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: INSERT INTO ARTIST (ARTIST_ID, ARTIST_NAME, DATE_OF_BIRTH) VALUES (?, ?, ?)
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ARTIST_ID:259, 2->ARTIST_NAME:'X', 3->DATE_OF_BIRTH:NULL]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: INSERT INTO PAINTING (ARTIST_ID, ESTIMATED_PRICE, GALLERY_ID, PAINTING_DESCRIPTION,
PAINTING_ID, PAINTING_TITLE) VALUES (?, ?, ?, ?, ?, ?)
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ARTIST_ID:NULL, 2->ESTIMATED_PRICE:NULL, 3->GALLERY_ID:NULL, 4->PAINTING_DESCRIPTION:NULL,
5->PAINTING_ID:257, 6->PAINTING_TITLE:'PY']
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ARTIST_ID:259, 2->ESTIMATED_PRICE:NULL, 3->GALLERY_ID:NULL, 4->PAINTING_DESCRIPTION:NULL,
5->PAINTING_ID:258, 6->PAINTING_TITLE:'PX']
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 1 query.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: UPDATE PAINTING SET ARTIST_ID = ? WHERE PAINTING_ID = ?
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logQueryParameters
INFO: [bind: 1->ARTIST_ID:259, 2->PAINTING_ID:257]
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logUpdateCount
INFO: === updated 1 row.
Dec 3, 2009 3:06:29 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Dec 3, 2009 3:06:30 PM org.apache.cayenne.access.QueryLogger logQueryStart
INFO: --- will run 1 query.
Dec 3, 2009 3:06:30 PM org.apache.cayenne.access.QueryLogger logBeginTransaction
INFO: --- transaction started.
Dec 3, 2009 3:06:30 PM org.apache.cayenne.access.QueryLogger logQuery
INFO: SELECT t0.ARTIST_ID, t0.PAINTING_ID, t0.GALLERY_ID, t0.PAINTING_DESCRIPTION, t0.ESTIMATED_PRICE,
t0.PAINTING_TITLE FROM PAINTING t0 WHERE t0.ARTIST_ID = ? [bind: 1->ARTIST_ID:259]
Dec 3, 2009 3:06:30 PM org.apache.cayenne.access.QueryLogger logSelectCount
INFO: === returned 2 rows. - took 1 ms.
Dec 3, 2009 3:06:30 PM org.apache.cayenne.access.QueryLogger logCommitTransaction
INFO: +++ transaction committed.
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.949 sec
Running org.apache.cayenne.DataRowTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
Running org.apache.cayenne.access.types.EnumTypeTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.cayenne.access.CustomQueryTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.cayenne.project.validator.DomainValidatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec

Results :

Failed tests: 
  testBlockShouldProcessDeleteOnExternalChange(org.apache.cayenne.access.DataContextDelegateSharedCacheTest)

Tests run: 2052, Failures: 1, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.

Please refer to /zonestorage/hudson/home/hudson/hudson/jobs/Cayenne-trunk/workspace/jdk/JDK
1.6 (latest)/testConnection/h2/trunk/framework/cayenne-jdk1.5-unpublished/target/surefire-reports
for the individual test results.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3 minutes 32 seconds
[INFO] Finished at: Thu Dec 03 15:06:31 UTC 2009
[INFO] Final Memory: 53M/188M
[INFO] ------------------------------------------------------------------------

Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler

2009-12-03T14:38:34Z

On Dec 3, 2009, at 4:22 PM, Mike Kienenberger wrote:

>  It doesn't make any sense to have a project-specific piece of  
> information
> stored in preferences.

And still we do that a lot already. There's a bunch of per-screen  
Modeler preferences stored per project (and not in user visible XML  
files). If you move to another machine, you lose it.

I think the difference here is in a mental view of the graph layout  
task. To you and Andrey it is a part of the ORM modeling work. To me  
it is not. It is a *local* user preference. Something a single  
developer would tweak to his or her liking, kind of like arranging  
icons on a desktop.

Let me give you a few examples of why sharing a layout might be bad:

* 2 developers on the project want to have different layouts, because  
they work with different parts of the model. So they group entities  
differently.

* A single developer rearranges the layout multiple times during the  
day as he goes from one task to another.

* 1 developer uses a 13" notebook, another - 31" screen. Developer 1  
has no choice, but to optimize the layout for his screen.

Andrus

Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler

2009-12-03T14:30:37Z

We can have some check box "save graph changes" for every graph. by default
it is false, and turns on if there were major changes (e.g. entity added) or
checked manually. Minor changes (entity moved, resized, etc) will not be
saved by default.
Anyways, I think this task is not of highest priority, and we need more
opinions to take decision

2009/12/3 Mike Kienenberger 

> I agree with Andrey.   It should be saved as part of the project.  It
> doesn't make any sense to have a project-specific piece of information
> stored in preferences.  If you copy your project to another machine,
> you lose the information.  If you delete the project, the information
> remains in preferences even though the project is gone.
>
> You should mark it as ignored if you don't want to put it in your SCM
> or if the noise bothers you.
>
>
> On Thu, Dec 3, 2009 at 9:03 AM, Andrus Adamchik 
> wrote:
> > I agree with the premise, but I had bad experience with other ORM tools
> > years ago that would save the layout together with the project, and then
> a
> > single unintended mouse move results in making the project "dirty" and
> > creates an underlying SCM change. IMO that was a distraction and created
> > constant commit noise.
> >
> > So essentially managing a pretty layout is a parallel task to the main
> task
> > of creating a model, and I don't want it to become a distraction. So
> maybe
> > we can make it a project property (persist-layout: true|false (default))?
> If
> > true, it will store the XML together with the project, if false, it will
> > store it in local preferences?
> >
> > Andrus
> >
> >
> > On Dec 3, 2009, at 3:47 PM, Andrey Razumovsky wrote:
> >>
> >> 2009/12/3 Andrus Adamchik 
> >>
> >>>
> >>> On Dec 3, 2009, at 3:31 PM, Andrus Adamchik wrote:
> >>>
> >>> * saving graphs info as .graph.xml (and restoring). Note
> >>> that
> >>>>>
> >>>>> this file will not be used in classic Cayenne runtime
> >>>>>
> >>>>
> >>> I think this can be tied to preferences and saved in ~/.cayenne/.
> Saving
> >>> it
> >>> in the project tree has SCM implications.
> >>>
> >>>
> >> I thought of that..
> >> Lets take your example. You've got an enormous project, so no layout can
> >> place entities without intersections. You spend half a day to organize
> it
> >> well.. Then what? How can other members of the team see your changes? It
> >> is
> >> even better when graph is in SCM - it is not a big file, and allows
> >> everyone
> >> to see it. Graph file is XML, so SVN should merge it correctly. The only
> >> thing you need is exclude it from packaged version of your project (if
> you
> >> want).
> >>
> >> At last resort you can add graph files to something like svn:ignore
> >
> >
>



-- 
Andrey

Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler

2009-12-03T14:22:25Z

I agree with Andrey.   It should be saved as part of the project.  It
doesn't make any sense to have a project-specific piece of information
stored in preferences.  If you copy your project to another machine,
you lose the information.  If you delete the project, the information
remains in preferences even though the project is gone.

You should mark it as ignored if you don't want to put it in your SCM
or if the noise bothers you.


On Thu, Dec 3, 2009 at 9:03 AM, Andrus Adamchik  wrote:
> I agree with the premise, but I had bad experience with other ORM tools
> years ago that would save the layout together with the project, and then a
> single unintended mouse move results in making the project "dirty" and
> creates an underlying SCM change. IMO that was a distraction and created
> constant commit noise.
>
> So essentially managing a pretty layout is a parallel task to the main task
> of creating a model, and I don't want it to become a distraction. So maybe
> we can make it a project property (persist-layout: true|false (default))? If
> true, it will store the XML together with the project, if false, it will
> store it in local preferences?
>
> Andrus
>
>
> On Dec 3, 2009, at 3:47 PM, Andrey Razumovsky wrote:
>>
>> 2009/12/3 Andrus Adamchik 
>>
>>>
>>> On Dec 3, 2009, at 3:31 PM, Andrus Adamchik wrote:
>>>
>>> * saving graphs info as .graph.xml (and restoring). Note
>>> that
>>>>>
>>>>> this file will not be used in classic Cayenne runtime
>>>>>
>>>>
>>> I think this can be tied to preferences and saved in ~/.cayenne/. Saving
>>> it
>>> in the project tree has SCM implications.
>>>
>>>
>> I thought of that..
>> Lets take your example. You've got an enormous project, so no layout can
>> place entities without intersections. You spend half a day to organize it
>> well.. Then what? How can other members of the team see your changes? It
>> is
>> even better when graph is in SCM - it is not a big file, and allows
>> everyone
>> to see it. Graph file is XML, so SVN should merge it correctly. The only
>> thing you need is exclude it from packaged version of your project (if you
>> want).
>>
>> At last resort you can add graph files to something like svn:ignore
>
>

Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler

2009-12-03T14:03:13Z

I agree with the premise, but I had bad experience with other ORM  
tools years ago that would save the layout together with the project,  
and then a single unintended mouse move results in making the project  
"dirty" and creates an underlying SCM change. IMO that was a  
distraction and created constant commit noise.

So essentially managing a pretty layout is a parallel task to the main  
task of creating a model, and I don't want it to become a distraction.  
So maybe we can make it a project property (persist-layout: true|false  
(default))? If true, it will store the XML together with the project,  
if false, it will store it in local preferences?

Andrus

On Dec 3, 2009, at 3:47 PM, Andrey Razumovsky wrote:
> 2009/12/3 Andrus Adamchik 
>
>>
>> On Dec 3, 2009, at 3:31 PM, Andrus Adamchik wrote:
>>
>> * saving graphs info as .graph.xml (and restoring).  
>> Note that
>>>> this file will not be used in classic Cayenne runtime
>>>>
>>>
>> I think this can be tied to preferences and saved in ~/.cayenne/.  
>> Saving it
>> in the project tree has SCM implications.
>>
>>
> I thought of that..
> Lets take your example. You've got an enormous project, so no layout  
> can
> place entities without intersections. You spend half a day to  
> organize it
> well.. Then what? How can other members of the team see your  
> changes? It is
> even better when graph is in SCM - it is not a big file, and allows  
> everyone
> to see it. Graph file is XML, so SVN should merge it correctly. The  
> only
> thing you need is exclude it from packaged version of your project  
> (if you
> want).
>
> At last resort you can add graph files to something like svn:ignore

Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler

2009-12-03T13:49:53Z

The ultimate goal is to add most model operations (add/remove/edit
entity/attribute/relationship...) to graph panel. Then everything takes its
place and you can edit model and organize graph at the same time

2009/12/3 Andrus Adamchik 

>
> On Dec 3, 2009, at 3:39 PM, Andrey Razumovsky wrote:
>
>  if you create projects from the start, you can constanlly
>> and sequentially organize the graph
>>
>
> Good point.
>
>

-- 
Andrey

Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler

2009-12-03T13:47:30Z

2009/12/3 Andrus Adamchik 

>
> On Dec 3, 2009, at 3:31 PM, Andrus Adamchik wrote:
>
>  * saving graphs info as .graph.xml (and restoring). Note that
>>> this file will not be used in classic Cayenne runtime
>>>
>>
> I think this can be tied to preferences and saved in ~/.cayenne/. Saving it
> in the project tree has SCM implications.
>
>
I thought of that..
Lets take your example. You've got an enormous project, so no layout can
place entities without intersections. You spend half a day to organize it
well.. Then what? How can other members of the team see your changes? It is
even better when graph is in SCM - it is not a big file, and allows everyone
to see it. Graph file is XML, so SVN should merge it correctly. The only
thing you need is exclude it from packaged version of your project (if you
want).

At last resort you can add graph files to something like svn:ignore

Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler

2009-12-03T13:42:20Z


On Dec 3, 2009, at 3:39 PM, Andrey Razumovsky wrote:

> if you create projects from the start, you can constanlly
> and sequentially organize the graph

Good point.

Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler

2009-12-03T13:40:00Z

On Dec 3, 2009, at 3:31 PM, Andrus Adamchik wrote:

>> * saving graphs info as .graph.xml (and restoring).  
>> Note that this file will not be used in classic Cayenne runtime

I think this can be tied to preferences and saved in ~/.cayenne/.  
Saving it in the project tree has SCM implications.

>> * grouping by datamaps (in fact, I've found that standard JGraph  
>> grouping doesn't look well on my models).

This (an maybe an ability to filter/group entities by some criteria)  
may be the answer to working with large schemas.

Andrus

Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler

2009-12-03T13:39:15Z

Well, I played with standard JGraph layouts for some time, this is the best
I found. Probably I will return to this research someday. But definitely we
can create big graphs on bigger sheet, then it well be less confusing.
On the other hand, if you create projects from the start, you can constanlly
and sequentially organize the graph, so it will not be so messy.

2009/12/3 Andrus Adamchik 

> Nice start!
>
> I wonder what we can do to scale it to large projects? E.g.:
>
>  http://people.apache.org/~aadamchik/class.png
>
> Coincidentally the same issue was discussed on a WebObjects mailing list
> today. It is not yet archived, and if I don't forget, I'll forward the links
> once it is archived.
>
> Andrus
>
>
>
> On Dec 2, 2009, at 4:50 PM, Andrey Razumovsky (JIRA) wrote:
>
>
>>   [
>> https://issues.apache.org/jira/browse/CAY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784856#action_12784856
>> ]
>>
>> Andrey Razumovsky commented on CAY-762:
>> ---------------------------------------
>>
>> First version is committed on 3.1 trunk and I welcome everyone to try it.
>> JGraph 5.13.0.0 is used as graph implementation.
>>
>> There are two types of diagrams - ER (for DbEntities) and Class (for
>> ObjEntities). They are avaliable through "Graph" tab of DataDomain
>> information panel.
>>
>> What IS done:
>> * drawing of entities with attributes and relationships between them,
>> showing arity of rels, inheritance
>> * quick showing entities in left-hand tree (using right-click context
>> menu), as well as some basic operation shortcuts
>> * lazy loading of graphs - they are not created until requested
>> * layout of firstly opened graph with entities (played a bit with jgraph
>> layouts, still not sure this is the best one). Note that opening a large
>> project may result in a complex web of entities
>> * saving graphs info as .graph.xml (and restoring). Note that
>> this file will not be used in classic Cayenne runtime
>> * synchronizing in both sides with left-hand tree
>> * scaling
>> * saving models as images
>> * undo support
>>
>> What IS NOT done:
>> * editing objects (e.g. entity names, attrs) in graph
>> * finding object on the graph from its info panel
>> * grouping by datamaps (in fact, I've found that standard JGraph grouping
>> doesn't look well on my models).
>>
>> Please post your comments
>>
>>  ERDiagram for Object Entities in Cayenne Modeler
>>> ------------------------------------------------
>>>
>>>               Key: CAY-762
>>>               URL: https://issues.apache.org/jira/browse/CAY-762
>>>           Project: Cayenne
>>>        Issue Type: New Feature
>>>        Components: CayenneModeler GUI
>>>  Affects Versions: 3.0
>>>          Reporter: Ahmed Mohombe
>>>          Assignee: Andrey Razumovsky
>>>           Fix For: 3.1M1
>>>
>>>
>>> Please add an ER Diagram to the Cayenne Modeler. This is the feature that
>>> I miss the most from WebObjects.
>>> For start it would be even enough to have  an ER Diagram View (so no
>>> interactive activities) - just display and layout of entities.
>>> I think this would help allot and would increase the productivity with CM
>>> - most people think visually.
>>> I don't think that it would be complicated to implement, the most
>>> complicated question to answer is what graph library is allowed to use, due
>>> to the restrictive "license compatibility" of the Apache license.
>>> Thanks in advance,
>>> Ahmed.
>>>
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>>
>


-- 
Andrey

Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler

2009-12-03T13:31:03Z

Nice start!

I wonder what we can do to scale it to large projects? E.g.:

   http://people.apache.org/~aadamchik/class.png

Coincidentally the same issue was discussed on a WebObjects mailing  
list today. It is not yet archived, and if I don't forget, I'll  
forward the links once it is archived.

Andrus


On Dec 2, 2009, at 4:50 PM, Andrey Razumovsky (JIRA) wrote:

>
>    [ https://issues.apache.org/jira/browse/CAY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784856

> #action_12784856 ]
>
> Andrey Razumovsky commented on CAY-762:
> ---------------------------------------
>
> First version is committed on 3.1 trunk and I welcome everyone to  
> try it.
> JGraph 5.13.0.0 is used as graph implementation.
>
> There are two types of diagrams - ER (for DbEntities) and Class (for  
> ObjEntities). They are avaliable through "Graph" tab of DataDomain  
> information panel.
>
> What IS done:
> * drawing of entities with attributes and relationships between  
> them, showing arity of rels, inheritance
> * quick showing entities in left-hand tree (using right-click  
> context menu), as well as some basic operation shortcuts
> * lazy loading of graphs - they are not created until requested
> * layout of firstly opened graph with entities (played a bit with  
> jgraph layouts, still not sure this is the best one). Note that  
> opening a large project may result in a complex web of entities
> * saving graphs info as .graph.xml (and restoring).  
> Note that this file will not be used in classic Cayenne runtime
> * synchronizing in both sides with left-hand tree
> * scaling
> * saving models as images
> * undo support
>
> What IS NOT done:
> * editing objects (e.g. entity names, attrs) in graph
> * finding object on the graph from its info panel
> * grouping by datamaps (in fact, I've found that standard JGraph  
> grouping doesn't look well on my models).
>
> Please post your comments
>
>> ERDiagram for Object Entities in Cayenne Modeler
>> ------------------------------------------------
>>
>>                Key: CAY-762
>>                URL: https://issues.apache.org/jira/browse/CAY-762
>>            Project: Cayenne
>>         Issue Type: New Feature
>>         Components: CayenneModeler GUI
>>   Affects Versions: 3.0
>>           Reporter: Ahmed Mohombe
>>           Assignee: Andrey Razumovsky
>>            Fix For: 3.1M1
>>
>>
>> Please add an ER Diagram to the Cayenne Modeler. This is the  
>> feature that I miss the most from WebObjects.
>> For start it would be even enough to have  an ER Diagram View (so  
>> no interactive activities) - just display and layout of entities.
>> I think this would help allot and would increase the productivity  
>> with CM - most people think visually.
>> I don't think that it would be complicated to implement, the most  
>> complicated question to answer is what graph library is allowed to  
>> use, due to the restrictive "license compatibility" of the Apache  
>> license.
>> Thanks in advance,
>> Ahmed.
>
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

RE: Cayenne Oracle tests

2009-12-03T12:46:21Z

Yeah... so much to do...

BTW I patially fixed that bug with oracle TIMESTAMP mapping. Think it will be fixed this weak.
Was idea to add JUnit, so I will try AccessStackAdapter.

Evgeny.

-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org] 
Sent: Thursday, December 03, 2009 3:39 PM
To: dev@cayenne.apache.org
Subject: Re: Cayenne Oracle tests

We don't have per-DB tests. There's some weak support for excluding  
certain tests on some DB's (see  
org.apache.cayenne.unit.AccessStackAdapter).

Olga recently did the research of an implementation of per-DB test  
capabilities. This hasn't been discussed yet in detail, but this is  
something that I'd like to have in 3.1... Specifically this would  
require migration of the tests to TestNG, and organizing the tests  
into "test groups". Each target database can be associated with one or  
more test groups. So DB-specific stuff can be placed in a DB-specific  
group.

For now AccessStackAdapter and subclasses are the only way to achieve  
that.

Andrus

On Dec 3, 2009, at 1:53 PM, �������� ������� wrote:

> Yeah. Thx...
> But what if I want to add some Oracle-specific test?
> Do we have some?
>
> Evgeny.
>
>
>
>
>
>
> -----Original Message-----
> From: Aristedes Maniatis [mailto:ari@maniatis.org]
> Sent: Thursday, December 03, 2009 1:44 PM
> To: dev@cayenne.apache.org
> Subject: Re: Cayenne Oracle tests
>
> On 3/12/09 8:50 PM, �������� ������� wrote:
>> Hello!
>>
>> Can some one explain me how Cayenne is tested over Oracle.
>> Just going to add some Oracle-specific JUnit test. How to do it?
>> Any example... notes... documentation?
>>
>> Evgeny.
>
> If you want to run the unit tests... http://cayenne.apache.org/running-unit-tests.html
>
>
> Ari
>
>
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>

Re: Cayenne Oracle tests

2009-12-03T12:38:57Z

We don't have per-DB tests. There's some weak support for excluding  
certain tests on some DB's (see  
org.apache.cayenne.unit.AccessStackAdapter).

Olga recently did the research of an implementation of per-DB test  
capabilities. This hasn't been discussed yet in detail, but this is  
something that I'd like to have in 3.1... Specifically this would  
require migration of the tests to TestNG, and organizing the tests  
into "test groups". Each target database can be associated with one or  
more test groups. So DB-specific stuff can be placed in a DB-specific  
group.

For now AccessStackAdapter and subclasses are the only way to achieve  
that.

Andrus

On Dec 3, 2009, at 1:53 PM, �������� ������� wrote:

> Yeah. Thx...
> But what if I want to add some Oracle-specific test?
> Do we have some?
>
> Evgeny.
>
>
>
>
>
>
> -----Original Message-----
> From: Aristedes Maniatis [mailto:ari@maniatis.org]
> Sent: Thursday, December 03, 2009 1:44 PM
> To: dev@cayenne.apache.org
> Subject: Re: Cayenne Oracle tests
>
> On 3/12/09 8:50 PM, �������� ������� wrote:
>> Hello!
>>
>> Can some one explain me how Cayenne is tested over Oracle.
>> Just going to add some Oracle-specific JUnit test. How to do it?
>> Any example... notes... documentation?
>>
>> Evgeny.
>
> If you want to run the unit tests... http://cayenne.apache.org/running-unit-tests.html
>
>
> Ari
>
>
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>

RE: Cayenne Oracle tests

2009-12-03T11:53:09Z

Yeah. Thx...
But what if I want to add some Oracle-specific test?
Do we have some?

Evgeny.


 



-----Original Message-----
From: Aristedes Maniatis [mailto:ari@maniatis.org] 
Sent: Thursday, December 03, 2009 1:44 PM
To: dev@cayenne.apache.org
Subject: Re: Cayenne Oracle tests

On 3/12/09 8:50 PM, �������� ������� wrote:
> Hello!
>
> Can some one explain me how Cayenne is tested over Oracle.
> Just going to add some Oracle-specific JUnit test. How to do it?
> Any example... notes... documentation?
>
> Evgeny.

If you want to run the unit tests... http://cayenne.apache.org/running-unit-tests.html


Ari


-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Re: Cayenne Oracle tests

2009-12-03T10:43:45Z

On 3/12/09 8:50 PM, �������� ������� wrote:
> Hello!
>
> Can some one explain me how Cayenne is tested over Oracle.
> Just going to add some Oracle-specific JUnit test. How to do it?
> Any example... notes... documentation?
>
> Evgeny.

If you want to run the unit tests... http://cayenne.apache.org/running-unit-tests.html


Ari


-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Cayenne Oracle tests

2009-12-03T09:50:26Z

Hello!

Can some one explain me how Cayenne is tested over Oracle.
Just going to add some Oracle-specific JUnit test. How to do it?
Any example... notes... documentation? 

Evgeny.







On Dec 2, 2009, at 6:16 PM, Evgeny Ryabitskiy (JIRA) wrote:
>    [ https://issues.apache.org/jira/browse/CAY-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784887

> #action_12784887 ]
>
> Evgeny Ryabitskiy commented on CAY-1323:
> ----------------------------------------
>
> I think I finished my Investigation. If you wish I can add some  
> JUnit for this UC.
>
> You can add "Fix Version" as you wish. But I think it should be  
> fixed in all branches (1.0, 2.0, 3.0).
> It is no expectable behavior.... As you wrote: "Cayenne Mapping can  
> only contain JDBC types"
>
> How to fix... mm have thoughts that OracleAdapter can help us...  
> need some time to look there inside
>
>> oracle.sql.TIMESTAMP in Result of query
>> ---------------------------------------
>>
>>                Key: CAY-1323
>>                URL: https://issues.apache.org/jira/browse/CAY-1323
>>            Project: Cayenne
>>         Issue Type: Bug
>>         Components: Cayenne Core Library
>>   Affects Versions: 2.0.5, 3.0 beta 1
>>           Reporter: Evgeny Ryabitskiy
>>           Assignee: Andrus Adamchik
>>        Attachments: cayenne.xml, OracleTimestampTest.java,  
>> OracleTimestampTestMap.map.xml
>>
>>
>> Result of query from column of timestamp type was mapped to  
>> oracle.sql.TIMESTAMP.
>> I think it should be mapped to standard JDBS TIMESTAMP
>> I am using latest official Oracle JDBC driver.
>
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

Re: [jira] Commented: (CAY-1323) oracle.sql.TIMESTAMP in Result of query

2009-12-02T17:25:41Z

Ok. Now it is much clear. Thx for explaining.

Evgeny.

2009/12/2 Andrus Adamchik :
> Hi Evgeny,
>
> Let me take this to dev... Thanks for providing all the information on the
> issue and working on the fix. This is rather valuable to Cayenne, as your
> system has a number of use cases that seem to be pretty unique in this
> community, and you can find things that nobody else will. (Also hope that
> your Apache account will be created soon, so that you can take over this
> Jira and commit it yourself)
>
>> As you wrote: "Cayenne Mapping can only contain JDBC types"
>
> Let me clarify. This was referring to the DB part of the mapping. On the
> Java part we can map any custom types. And we do in fact. Cayenne is
> definitely not limited to the types listed in the JDBC spec, again on the
> object end of the mapping.
>
>> How to fix... mm have thoughts that OracleAdapter can help us... need some
>> time to look there inside
>
> Yes please.
>
> Let me comment on the fix versions to avoid misunderstanding. The fix
> versions will depend on the nature of the fix and the definition of the
> problem. Just returning an Oracle type from an unmapped query is IMO not a
> bug (actually it looks more like a bug in Oracle driver from your examples,
> and what I found via Google). On the other hand returning correct value from
> SQLTemplate with an explicit #result(), is something that we need to handle
> correctly ourselves.
>
> So the second case should probably be fixed on all stable branches.
>
> The first case would require us to redefine how Cayenne works. For instance
> we may decide that from 3.1 all Oracle internal types should be converted to
> JDBC default types (unless otherwise specified by the user). But we won't be
> able to include that change in the "stable" releases.
>
> Andrus
>
>
> On Dec 2, 2009, at 6:16 PM, Evgeny Ryabitskiy (JIRA) wrote:
>>
>> � [
>> https://issues.apache.org/jira/browse/CAY-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784887#action_12784887
>> ]
>>
>> Evgeny Ryabitskiy commented on CAY-1323:
>> ----------------------------------------
>>
>> I think I finished my Investigation. If you wish I can add some JUnit for
>> this UC.
>>
>> You can add "Fix Version" as you wish. But I think it should be fixed in
>> all branches (1.0, 2.0, 3.0).
>> It is no expectable behavior.... As you wrote: "Cayenne Mapping can only
>> contain JDBC types"
>>
>> How to fix... mm have thoughts that OracleAdapter can help us... need some
>> time to look there inside
>>
>>> oracle.sql.TIMESTAMP in Result of query
>>> ---------------------------------------
>>>
>>> � � � � � � � Key: CAY-1323
>>> � � � � � � � URL: https://issues.apache.org/jira/browse/CAY-1323
>>> � � � � � Project: Cayenne
>>> � � � �Issue Type: Bug
>>> � � � �Components: Cayenne Core Library
>>> �Affects Versions: 2.0.5, 3.0 beta 1
>>> � � � � �Reporter: Evgeny Ryabitskiy
>>> � � � � �Assignee: Andrus Adamchik
>>> � � � Attachments: cayenne.xml, OracleTimestampTest.java,
>>> OracleTimestampTestMap.map.xml
>>>
>>>
>>> Result of query from column of timestamp type was mapped to
>>> oracle.sql.TIMESTAMP.
>>> I think it should be mapped to standard JDBS TIMESTAMP
>>> I am using latest official Oracle JDBC driver.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>
>

Re: [jira] Commented: (CAY-1323) oracle.sql.TIMESTAMP in Result of query

2009-12-02T16:38:36Z

Hi Evgeny,

Let me take this to dev... Thanks for providing all the information on  
the issue and working on the fix. This is rather valuable to Cayenne,  
as your system has a number of use cases that seem to be pretty unique  
in this community, and you can find things that nobody else will.  
(Also hope that your Apache account will be created soon, so that you  
can take over this Jira and commit it yourself)

> As you wrote: "Cayenne Mapping can only contain JDBC types"

Let me clarify. This was referring to the DB part of the mapping. On  
the Java part we can map any custom types. And we do in fact. Cayenne  
is definitely not limited to the types listed in the JDBC spec, again  
on the object end of the mapping.

> How to fix... mm have thoughts that OracleAdapter can help us...  
> need some time to look there inside

Yes please.

Let me comment on the fix versions to avoid misunderstanding. The fix  
versions will depend on the nature of the fix and the definition of  
the problem. Just returning an Oracle type from an unmapped query is  
IMO not a bug (actually it looks more like a bug in Oracle driver from  
your examples, and what I found via Google). On the other hand  
returning correct value from SQLTemplate with an explicit #result(),  
is something that we need to handle correctly ourselves.

So the second case should probably be fixed on all stable branches.

The first case would require us to redefine how Cayenne works. For  
instance we may decide that from 3.1 all Oracle internal types should  
be converted to JDBC default types (unless otherwise specified by the  
user). But we won't be able to include that change in the "stable"  
releases.

Andrus

On Dec 2, 2009, at 6:16 PM, Evgeny Ryabitskiy (JIRA) wrote:
>    [ https://issues.apache.org/jira/browse/CAY-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784887

> #action_12784887 ]
>
> Evgeny Ryabitskiy commented on CAY-1323:
> ----------------------------------------
>
> I think I finished my Investigation. If you wish I can add some  
> JUnit for this UC.
>
> You can add "Fix Version" as you wish. But I think it should be  
> fixed in all branches (1.0, 2.0, 3.0).
> It is no expectable behavior.... As you wrote: "Cayenne Mapping can  
> only contain JDBC types"
>
> How to fix... mm have thoughts that OracleAdapter can help us...  
> need some time to look there inside
>
>> oracle.sql.TIMESTAMP in Result of query
>> ---------------------------------------
>>
>>                Key: CAY-1323
>>                URL: https://issues.apache.org/jira/browse/CAY-1323
>>            Project: Cayenne
>>         Issue Type: Bug
>>         Components: Cayenne Core Library
>>   Affects Versions: 2.0.5, 3.0 beta 1
>>           Reporter: Evgeny Ryabitskiy
>>           Assignee: Andrus Adamchik
>>        Attachments: cayenne.xml, OracleTimestampTest.java,  
>> OracleTimestampTestMap.map.xml
>>
>>
>> Result of query from column of timestamp type was mapped to  
>> oracle.sql.TIMESTAMP.
>> I think it should be mapped to standard JDBS TIMESTAMP
>> I am using latest official Oracle JDBC driver.
>
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

Re: [jira] Created: (CAY-1324) Update quick start tutorials

2009-12-02T10:45:17Z

Yep. Thanks for mentioning. I'll add it to the TODO list.

Andrus

On Dec 2, 2009, at 12:41 PM, Andrey Razumovsky wrote:

> Hi Andrus,
>
> Can we also have some docs for embeddables? It'd be great to see some
> examples
>
> -- 
> Andrey

Re: [jira] Created: (CAY-1324) Update quick start tutorials

2009-12-02T10:41:23Z

Hi Andrus,

Can we also have some docs for embeddables? It'd be great to see some
examples

-- 
Andrey

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-02T07:31:01Z

Sure. I am fine with keeping it as well. I guess this is mainly a  
documentation issue - it has to be mentioned that this is just one  
possible usage pattern, not *the* way to access ObjectContext.

Andrus

On Dec 1, 2009, at 8:51 PM, Michael Gentry wrote:

> I agree with Andrey here.  I think it is better for Cayenne to provide
> this in a consistent/standardized way for those who want it rather
> than requiring people to roll their own each time.  Those who need
> something more complex can implement something more complex, but let's
> keep the common case easy/standard.
>
> mrg
>
>
> On Tue, Dec 1, 2009 at 1:29 PM, Andrey Razumovsky
>  wrote:
>> 2009/12/1 Andrus Adamchik 
>>
>>> This is just a convenience in Cayenne. Nobody's forced to use it.  
>>> I will go
>>> as far as to suggest to remove it from Cayenne 3.1 as a built-in  
>>> feature,
>>> and just document it as a possible design pattern in a user  
>>> application.
>>>
>>>
>> I'm -1. We can see some profit in moving it from BC class (say, to  
>> new
>> "Cayenne" utility). But I'm sure it is widely used by everyone who  
>> uses
>> Cayenne in web apps (or maybe even in desktop apps)
>>
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-01T18:51:35Z

I agree with Andrey here.  I think it is better for Cayenne to provide
this in a consistent/standardized way for those who want it rather
than requiring people to roll their own each time.  Those who need
something more complex can implement something more complex, but let's
keep the common case easy/standard.

mrg

On Tue, Dec 1, 2009 at 1:29 PM, Andrey Razumovsky
 wrote:
> 2009/12/1 Andrus Adamchik 
>
>> This is just a convenience in Cayenne. Nobody's forced to use it. I will go
>> as far as to suggest to remove it from Cayenne 3.1 as a built-in feature,
>> and just document it as a possible design pattern in a user application.
>>
>>
> I'm -1. We can see some profit in moving it from BC class (say, to new
> "Cayenne" utility). But I'm sure it is widely used by everyone who uses
> Cayenne in web apps (or maybe even in desktop apps)
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-01T18:29:25Z

2009/12/1 Andrus Adamchik 

> This is just a convenience in Cayenne. Nobody's forced to use it. I will go
> as far as to suggest to remove it from Cayenne 3.1 as a built-in feature,
> and just document it as a possible design pattern in a user application.
>
>
I'm -1. We can see some profit in moving it from BC class (say, to new
"Cayenne" utility). But I'm sure it is widely used by everyone who uses
Cayenne in web apps (or maybe even in desktop apps)

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-01T16:20:28Z

On Dec 1, 2009, at 6:12 PM, Evgeny Ryabitskiy wrote:

> Transaction is not aggregated
> to DataDomain (inside called static method of Transaction class) how I
> was thinking before.

Well, Domain acts as a factory for the transaction, based on its own  
configuration. In 3.1 we'll have a DI container that is a factory of  
everything. Although there will be 1 DI container per Domain. So it is  
not going to change in 3.1.

> Callbacks can be add after initialization as a set of Delegates (now
> there can be only one so I can't say this transaction is fully
> cross-domain working).

Yeah I also don't like a single delegate model (and may change that in  
3.1). Nothing would prevent you from aggregating multiple delegates  
within one delegate on your own, but since we are talking about  
possible improvements, this is a valid point.

Andrus

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-01T16:12:47Z

> if you have ideas, �let's discuss them.

So first my idea is to change this method (It's confusing!!!):

domain.createTransaction();

A spend some time looking through code. Transaction is not aggregated
to DataDomain (inside called static method of Transaction class) how I
was thinking before. Only thing why it's where is parameter with
defines to use External or Internal Transaction and... some Delegate
for callbacks.
If it's singleton and can be used across several DataDomains it should
be more oblivious if we initialize it as a Singleton via static
method.

Callbacks can be add after initialization as a set of Delegates (now
there can be only one so I can't say this transaction is fully
cross-domain working).
What I want to say: If we are using it as Singleton (in scope of one
thread) then let's make it friendly-user singleton, not a headache for
developers who are constructing huge system with multiple domains :)

Evgeny.

>
>>> transactions, and while addressing one use case it breaks others (i.e.
>>> other
>>> users may need a single commit point across multiple DataDomains).
>>
>> Ok. Actually I has no differences between several domain-local
>> transactions and one huge that is across multiple DataDomains.
>> The question is Transaction is working well across multiple DataDomains?
>
> There's nothing magical about Transactions. In Cayenne they are a store of
> JDBC Connection to ensure that multiple sub-operations within a given
> operation get the same connection and consequently operate on the same db
> data version.
>
> 2 possible caveats between domains when they reuse transactions:
>
> * They should both use either external or internal transactions (i.e. the
> same transaction strategy).
> * If they want completely separate connections, DataNode names should not
> match. If they want to reuse connections from each other, they DataNode
> names should match.
>
> Andrus
>
>
>
>
>
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-01T15:00:17Z

On Dec 1, 2009, at 4:29 PM, Evgeny Ryabitskiy wrote:

> It's a crutch :/

Possibly. If we are to redesign public transaction API in Cayenne,  
let's looks at the big picture then and see what problems we are  
trying to solve. IIRC it was mentioned before that we can make  
*manual* transaction management more user-friendly (automatic is as  
friendly as it gets)... I am not sure how (or rather my ideas go in  
the direction of allowing attaching arbitrary objects to transactions,  
maybe not something you care about), but if you have ideas,  let's  
discuss them.

>> transactions, and while addressing one use case it breaks others  
>> (i.e. other
>> users may need a single commit point across multiple DataDomains).
>
> Ok. Actually I has no differences between several domain-local
> transactions and one huge that is across multiple DataDomains.
> The question is Transaction is working well across multiple  
> DataDomains?

There's nothing magical about Transactions. In Cayenne they are a  
store of JDBC Connection to ensure that multiple sub-operations within  
a given operation get the same connection and consequently operate on  
the same db data version.

2 possible caveats between domains when they reuse transactions:

* They should both use either external or internal transactions (i.e.  
the same transaction strategy).
* If they want completely separate connections, DataNode names should  
not match. If they want to reuse connections from each other, they  
DataNode names should match.

Andrus

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-01T14:29:57Z

> So here is how you can address your problem - unbind outer transaction from
> the thread when the nested transaction is started, and then rebind it back
> after inner commit/rollback:
>
> Transaction outer = Transaction.getThreadTransaction();
> try {
> � Transaction inner = ... // create
> � Transaction.bindThreadTransaction(inner);
>
> � ... // do work
> }
> finally {
> � Transaction.bindThreadTransaction(outer);
> }

It's a crutch :/

> transactions, and while addressing one use case it breaks others (i.e. other
> users may need a single commit point across multiple DataDomains).

Ok. Actually I has no differences between several domain-local
transactions and one huge that is across multiple DataDomains.
The question is Transaction is working well across multiple DataDomains?
When I am looking at code and see: someDomain.createTransaction() I
don't expect for this transaction to work across another
DataDomain....

Evgeny.

>
> On Dec 1, 2009, at 3:41 PM, Evgeny Ryabitskiy wrote:
>
>> Manual? I create them manually by calling domain1.createTransaction()
>> and domain2.createTransaction().
>>
>> How it happen: One method from Module 1 do some queries (first domain)
>> then call method from Module 2 that is also doing some queries (second
>> domain), after method from module 2 finished: method from module 1 is
>> doing more queries.
>>
>> So it's like an "nested" transaction (from mod 2) but is performed on
>> another DataDomain (it's another DB server) and absolutely isolated
>> from huge "outer" transaction (mod 1).
>> But I want to control both! and separately...
>>
>> Evgeny.
>>
>>
>>
>> 2009/12/1 Andrus Adamchik :
>>>
>>> Are those manual transactions? (I.e. how does it happen that transaction
>>> scopes overlap between two queries?)
>>>
>>> Also you can reuse the current thread transaction between multiple
>>> domains.
>>> As I said, connections are scoped by DataNode name, so the same
>>> transaction
>>> will return 2 separate connections for 2 queries run against 2 different
>>> nodes.
>>>
>>> Andrus
>>>
>>> On Dec 1, 2009, at 3:27 PM, Evgeny Ryabitskiy wrote:
>>>
>>>> Problem in multiple Domains.
>>>> When I am creating transaction I am creating it's for specific
>>>> DataDomain (like a DataContext).
>>>> When I have 2 Modules with dedicated DataDomains (so it will be 2
>>>> DataDomains) I can create 2 Transactions
>>>> (domain.createTransaction()).
>>>>
>>>> But to thread I can bind only one. Then when I start performing queries
>>>> I
>>>> got:
>>>> 1)First Domain Transaction is binded and handled normally
>>>> 2)Second Domain Transaction is override by first DataDomain. So when I
>>>> perform query for second: ThreadLocals return Transaction for firs
>>>> Domain.
>>>>
>>>> Evgeny
>>>>
>>>>
>>>>
>>>> 2009/12/1 Andrus Adamchik :
>>>>>
>>>>> Singletons are bad in a general purpose framework, like Cayenne. No
>>>>> question
>>>>> about that. Per your description even thread-local singletons can be
a
>>>>> problem, which is less obvious to me, but I guess real in some
>>>>> circumstances. So let's see what those are.
>>>>>
>>>>>> 2)DataContext.getThreadLocal()
>>>>>> Solved by own ThreadLocal for each module. (modules can work in one
>>>>>> thread)
>>>>>> //also spend some time
>>>>>
>>>>> This is just a convenience in Cayenne. Nobody's forced to use it. I
>>>>> will
>>>>> go
>>>>> as far as to suggest to remove it from Cayenne 3.1 as a built-in
>>>>> feature,
>>>>> and just document it as a possible design pattern in a user
>>>>> application.
>>>>>
>>>>>> 3)Transaction.getThreadTransaction()
>>>>>> this is killing one!!!
>>>>>> using of own ThreadLocal doesn't help.
>>>>>> It's hard-coded in performing Query to use this singleton
>>>>>> Transaction.getThreadTransaction()
>>>>>> And that is really huge problem for me.
>>>>>
>>>>> J2EE pattern of tying a transaction to an execution thread, even if
>>>>> multiple
>>>>> data sources are involved, makes sense as it allows to commit/rollback
>>>>> multiple things at once. Cayenne Transaction sort of follows that. JDBC
>>>>> connections within the transaction are scoped by DataNode name. So what
>>>>> exactly is the problem?
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>>
>>>>> On Dec 1, 2009, at 2:44 PM, Evgeny Ryabitskiy wrote:
>>>>>
>>>>>> Hello 2 everyone!
>>>>>>
>>>>>> Today I one more time thinking about singleton pattern and it's hard
>>>>>> usssage in Cayenne.
>>>>>>
>>>>>> So.. I have several modules, each has own DomainConfig file and
>>>>>> connection to it's DataBase. Sometimes there can be used different
DB
>>>>>> servers and even different DB types (usually it's Oracle and MS SQL,
>>>>>> sometimes Sybase).
>>>>>>
>>>>>> Singletons:
>>>>>> 1) Configuration.getSharedConfiguration()
>>>>>> This problem is solved:
>>>>>> DefaultConfiguration conf = new
>>>>>> DefaultConfiguration("module1-cayenne.xml");
>>>>>> conf .initialize;
>>>>>> conf.getDomain();
>>>>>> //spend some time to find solution... everywhere examples with
>>>>>> SharedConfiguration
>>>>>>
>>>>>> 2)DataContext.getThreadLocal()
>>>>>> Solved by own ThreadLocal for each module. (modules can work in one
>>>>>> thread)
>>>>>> //also spend some time
>>>>>>
>>>>>> 3)Transaction.getThreadTransaction()
>>>>>> this is killing one!!!
>>>>>> using of own ThreadLocal doesn't help.
>>>>>> It's hard-coded in performing Query to use this singleton
>>>>>> Transaction.getThreadTransaction()
>>>>>> And that is really huge problem for me.
>>>>>>
>>>>>> So me suggestion is to move this ThreadLocal to DataDomain. Still
can
>>>>>> use singleton API for standalone applications.
>>>>>> Also we can move DataContext to DataDomain.
>>>>>>
>>>>>> Evgeny.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-01T13:56:29Z

Calling Cayenne transactions "singletons" is not really accurate, as  
they are thread-local and scoped, and you can control that scope if  
you have to. So here is how you can address your problem - unbind  
outer transaction from the thread when the nested transaction is  
started, and then rebind it back after inner commit/rollback:

Transaction outer = Transaction.getThreadTransaction();
try {
    Transaction inner = ... // create
    Transaction.bindThreadTransaction(inner);

    ... // do work
}
finally {
    Transaction.bindThreadTransaction(outer);
}

I am undecided on whether DataDomain-scoped transactions is a good  
idea going forward. This goes against most J2EE users expectations  
about transactions, and while addressing one use case it breaks others  
(i.e. other users may need a single commit point across multiple  
DataDomains).

Andrus


On Dec 1, 2009, at 3:41 PM, Evgeny Ryabitskiy wrote:

> Manual? I create them manually by calling domain1.createTransaction()
> and domain2.createTransaction().
>
> How it happen: One method from Module 1 do some queries (first domain)
> then call method from Module 2 that is also doing some queries (second
> domain), after method from module 2 finished: method from module 1 is
> doing more queries.
>
> So it's like an "nested" transaction (from mod 2) but is performed on
> another DataDomain (it's another DB server) and absolutely isolated
> from huge "outer" transaction (mod 1).
> But I want to control both! and separately...
>
> Evgeny.
>
>
>
> 2009/12/1 Andrus Adamchik :
>> Are those manual transactions? (I.e. how does it happen that  
>> transaction
>> scopes overlap between two queries?)
>>
>> Also you can reuse the current thread transaction between multiple  
>> domains.
>> As I said, connections are scoped by DataNode name, so the same  
>> transaction
>> will return 2 separate connections for 2 queries run against 2  
>> different
>> nodes.
>>
>> Andrus
>>
>> On Dec 1, 2009, at 3:27 PM, Evgeny Ryabitskiy wrote:
>>
>>> Problem in multiple Domains.
>>> When I am creating transaction I am creating it's for specific
>>> DataDomain (like a DataContext).
>>> When I have 2 Modules with dedicated DataDomains (so it will be 2
>>> DataDomains) I can create 2 Transactions
>>> (domain.createTransaction()).
>>>
>>> But to thread I can bind only one. Then when I start performing  
>>> queries I
>>> got:
>>> 1)First Domain Transaction is binded and handled normally
>>> 2)Second Domain Transaction is override by first DataDomain. So  
>>> when I
>>> perform query for second: ThreadLocals return Transaction for firs
>>> Domain.
>>>
>>> Evgeny
>>>
>>>
>>>
>>> 2009/12/1 Andrus Adamchik :
>>>>
>>>> Singletons are bad in a general purpose framework, like Cayenne. No
>>>> question
>>>> about that. Per your description even thread-local singletons can  
>>>> be a
>>>> problem, which is less obvious to me, but I guess real in some
>>>> circumstances. So let's see what those are.
>>>>
>>>>> 2)DataContext.getThreadLocal()
>>>>> Solved by own ThreadLocal for each module. (modules can work in  
>>>>> one
>>>>> thread)
>>>>> //also spend some time
>>>>
>>>> This is just a convenience in Cayenne. Nobody's forced to use it.  
>>>> I will
>>>> go
>>>> as far as to suggest to remove it from Cayenne 3.1 as a built-in  
>>>> feature,
>>>> and just document it as a possible design pattern in a user  
>>>> application.
>>>>
>>>>> 3)Transaction.getThreadTransaction()
>>>>> this is killing one!!!
>>>>> using of own ThreadLocal doesn't help.
>>>>> It's hard-coded in performing Query to use this singleton
>>>>> Transaction.getThreadTransaction()
>>>>> And that is really huge problem for me.
>>>>
>>>> J2EE pattern of tying a transaction to an execution thread, even if
>>>> multiple
>>>> data sources are involved, makes sense as it allows to commit/ 
>>>> rollback
>>>> multiple things at once. Cayenne Transaction sort of follows  
>>>> that. JDBC
>>>> connections within the transaction are scoped by DataNode name.  
>>>> So what
>>>> exactly is the problem?
>>>>
>>>> Andrus
>>>>
>>>>
>>>>
>>>> On Dec 1, 2009, at 2:44 PM, Evgeny Ryabitskiy wrote:
>>>>
>>>>> Hello 2 everyone!
>>>>>
>>>>> Today I one more time thinking about singleton pattern and it's  
>>>>> hard
>>>>> usssage in Cayenne.
>>>>>
>>>>> So.. I have several modules, each has own DomainConfig file and
>>>>> connection to it's DataBase. Sometimes there can be used  
>>>>> different DB
>>>>> servers and even different DB types (usually it's Oracle and MS  
>>>>> SQL,
>>>>> sometimes Sybase).
>>>>>
>>>>> Singletons:
>>>>> 1) Configuration.getSharedConfiguration()
>>>>> This problem is solved:
>>>>> DefaultConfiguration conf = new
>>>>> DefaultConfiguration("module1-cayenne.xml");
>>>>> conf .initialize;
>>>>> conf.getDomain();
>>>>> //spend some time to find solution... everywhere examples with
>>>>> SharedConfiguration
>>>>>
>>>>> 2)DataContext.getThreadLocal()
>>>>> Solved by own ThreadLocal for each module. (modules can work in  
>>>>> one
>>>>> thread)
>>>>> //also spend some time
>>>>>
>>>>> 3)Transaction.getThreadTransaction()
>>>>> this is killing one!!!
>>>>> using of own ThreadLocal doesn't help.
>>>>> It's hard-coded in performing Query to use this singleton
>>>>> Transaction.getThreadTransaction()
>>>>> And that is really huge problem for me.
>>>>>
>>>>> So me suggestion is to move this ThreadLocal to DataDomain.  
>>>>> Still can
>>>>> use singleton API for standalone applications.
>>>>> Also we can move DataContext to DataDomain.
>>>>>
>>>>> Evgeny.
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-01T13:41:58Z

Manual? I create them manually by calling domain1.createTransaction()
and domain2.createTransaction().

How it happen: One method from Module 1 do some queries (first domain)
then call method from Module 2 that is also doing some queries (second
domain), after method from module 2 finished: method from module 1 is
doing more queries.

So it's like an "nested" transaction (from mod 2) but is performed on
another DataDomain (it's another DB server) and absolutely isolated
from huge "outer" transaction (mod 1).
 But I want to control both! and separately...

Evgeny.



2009/12/1 Andrus Adamchik :
> Are those manual transactions? (I.e. how does it happen that transaction
> scopes overlap between two queries?)
>
> Also you can reuse the current thread transaction between multiple domains.
> As I said, connections are scoped by DataNode name, so the same transaction
> will return 2 separate connections for 2 queries run against 2 different
> nodes.
>
> Andrus
>
> On Dec 1, 2009, at 3:27 PM, Evgeny Ryabitskiy wrote:
>
>> Problem in multiple Domains.
>> When I am creating transaction I am creating it's for specific
>> DataDomain (like a DataContext).
>> When I have 2 Modules with dedicated DataDomains (so it will be 2
>> DataDomains) I can create 2 Transactions
>> (domain.createTransaction()).
>>
>> But to thread I can bind only one. Then when I start performing queries I
>> got:
>> 1)First Domain Transaction is binded and handled normally
>> 2)Second Domain Transaction is override by first DataDomain. So when I
>> perform query for second: ThreadLocals return Transaction for firs
>> Domain.
>>
>> Evgeny
>>
>>
>>
>> 2009/12/1 Andrus Adamchik :
>>>
>>> Singletons are bad in a general purpose framework, like Cayenne. No
>>> question
>>> about that. Per your description even thread-local singletons can be a
>>> problem, which is less obvious to me, but I guess real in some
>>> circumstances. So let's see what those are.
>>>
>>>> 2)DataContext.getThreadLocal()
>>>> Solved by own ThreadLocal for each module. (modules can work in one
>>>> thread)
>>>> //also spend some time
>>>
>>> This is just a convenience in Cayenne. Nobody's forced to use it. I will
>>> go
>>> as far as to suggest to remove it from Cayenne 3.1 as a built-in feature,
>>> and just document it as a possible design pattern in a user application.
>>>
>>>> 3)Transaction.getThreadTransaction()
>>>> this is killing one!!!
>>>> using of own ThreadLocal doesn't help.
>>>> It's hard-coded in performing Query to use this singleton
>>>> Transaction.getThreadTransaction()
>>>> And that is really huge problem for me.
>>>
>>> J2EE pattern of tying a transaction to an execution thread, even if
>>> multiple
>>> data sources are involved, makes sense as it allows to commit/rollback
>>> multiple things at once. Cayenne Transaction sort of follows that. JDBC
>>> connections within the transaction are scoped by DataNode name. So what
>>> exactly is the problem?
>>>
>>> Andrus
>>>
>>>
>>>
>>> On Dec 1, 2009, at 2:44 PM, Evgeny Ryabitskiy wrote:
>>>
>>>> Hello 2 everyone!
>>>>
>>>> Today I one more time thinking about singleton pattern and it's hard
>>>> usssage in Cayenne.
>>>>
>>>> So.. I have several modules, each has own DomainConfig file and
>>>> connection to it's DataBase. Sometimes there can be used different DB
>>>> servers and even different DB types (usually it's Oracle and MS SQL,
>>>> sometimes Sybase).
>>>>
>>>> Singletons:
>>>> 1) Configuration.getSharedConfiguration()
>>>> This problem is solved:
>>>> DefaultConfiguration conf = new
>>>> DefaultConfiguration("module1-cayenne.xml");
>>>> conf .initialize;
>>>> conf.getDomain();
>>>> //spend some time to find solution... everywhere examples with
>>>> SharedConfiguration
>>>>
>>>> 2)DataContext.getThreadLocal()
>>>> Solved by own ThreadLocal for each module. (modules can work in one
>>>> thread)
>>>> //also spend some time
>>>>
>>>> 3)Transaction.getThreadTransaction()
>>>> this is killing one!!!
>>>> using of own ThreadLocal doesn't help.
>>>> It's hard-coded in performing Query to use this singleton
>>>> Transaction.getThreadTransaction()
>>>> And that is really huge problem for me.
>>>>
>>>> So me suggestion is to move this ThreadLocal to DataDomain. Still can
>>>> use singleton API for standalone applications.
>>>> Also we can move DataContext to DataDomain.
>>>>
>>>> Evgeny.
>>>>
>>>
>>>
>>
>
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-01T13:31:15Z

Are those manual transactions? (I.e. how does it happen that  
transaction scopes overlap between two queries?)

Also you can reuse the current thread transaction between multiple  
domains. As I said, connections are scoped by DataNode name, so the  
same transaction will return 2 separate connections for 2 queries run  
against 2 different nodes.

Andrus

On Dec 1, 2009, at 3:27 PM, Evgeny Ryabitskiy wrote:

> Problem in multiple Domains.
> When I am creating transaction I am creating it's for specific
> DataDomain (like a DataContext).
> When I have 2 Modules with dedicated DataDomains (so it will be 2
> DataDomains) I can create 2 Transactions
> (domain.createTransaction()).
>
> But to thread I can bind only one. Then when I start performing  
> queries I got:
> 1)First Domain Transaction is binded and handled normally
> 2)Second Domain Transaction is override by first DataDomain. So when I
> perform query for second: ThreadLocals return Transaction for firs
> Domain.
>
> Evgeny
>
>
>
> 2009/12/1 Andrus Adamchik :
>> Singletons are bad in a general purpose framework, like Cayenne. No  
>> question
>> about that. Per your description even thread-local singletons can  
>> be a
>> problem, which is less obvious to me, but I guess real in some
>> circumstances. So let's see what those are.
>>
>>> 2)DataContext.getThreadLocal()
>>> Solved by own ThreadLocal for each module. (modules can work in one
>>> thread)
>>> //also spend some time
>>
>> This is just a convenience in Cayenne. Nobody's forced to use it. I  
>> will go
>> as far as to suggest to remove it from Cayenne 3.1 as a built-in  
>> feature,
>> and just document it as a possible design pattern in a user  
>> application.
>>
>>> 3)Transaction.getThreadTransaction()
>>> this is killing one!!!
>>> using of own ThreadLocal doesn't help.
>>> It's hard-coded in performing Query to use this singleton
>>> Transaction.getThreadTransaction()
>>> And that is really huge problem for me.
>>
>> J2EE pattern of tying a transaction to an execution thread, even if  
>> multiple
>> data sources are involved, makes sense as it allows to commit/ 
>> rollback
>> multiple things at once. Cayenne Transaction sort of follows that.  
>> JDBC
>> connections within the transaction are scoped by DataNode name. So  
>> what
>> exactly is the problem?
>>
>> Andrus
>>
>>
>>
>> On Dec 1, 2009, at 2:44 PM, Evgeny Ryabitskiy wrote:
>>
>>> Hello 2 everyone!
>>>
>>> Today I one more time thinking about singleton pattern and it's hard
>>> usssage in Cayenne.
>>>
>>> So.. I have several modules, each has own DomainConfig file and
>>> connection to it's DataBase. Sometimes there can be used different  
>>> DB
>>> servers and even different DB types (usually it's Oracle and MS SQL,
>>> sometimes Sybase).
>>>
>>> Singletons:
>>> 1) Configuration.getSharedConfiguration()
>>> This problem is solved:
>>> DefaultConfiguration conf = new
>>> DefaultConfiguration("module1-cayenne.xml");
>>> conf .initialize;
>>> conf.getDomain();
>>> //spend some time to find solution... everywhere examples with
>>> SharedConfiguration
>>>
>>> 2)DataContext.getThreadLocal()
>>> Solved by own ThreadLocal for each module. (modules can work in one
>>> thread)
>>> //also spend some time
>>>
>>> 3)Transaction.getThreadTransaction()
>>> this is killing one!!!
>>> using of own ThreadLocal doesn't help.
>>> It's hard-coded in performing Query to use this singleton
>>> Transaction.getThreadTransaction()
>>> And that is really huge problem for me.
>>>
>>> So me suggestion is to move this ThreadLocal to DataDomain. Still  
>>> can
>>> use singleton API for standalone applications.
>>> Also we can move DataContext to DataDomain.
>>>
>>> Evgeny.
>>>
>>
>>
>

Re: [jira] Created: (CAY-1322) Multiple Transactions: Migrate from Singleton pattern

2009-12-01T13:31:04Z

Ok. Maybe I have little bit rushed :)


2009/12/1 Andrus Adamchik :
> I guess that's a bit premature. Let's figure out if there is a problem
> before opening a Jira. "Jiras" are "tasks", i.e. specific action items. So
> I'd rather we come to some consensus on what needs to be done firs, and then
> Jira action items.
>
> Andrus
>
> On Dec 1, 2009, at 2:50 PM, Evgeny Ryabitskiy (JIRA) wrote:
>
>> Multiple Transactions: Migrate from Singleton pattern
>> -----------------------------------------------------
>>
>> � � � � � � � �Key: CAY-1322
>> � � � � � � � �URL: https://issues.apache.org/jira/browse/CAY-1322
>> � � � � � �Project: Cayenne
>> � � � � Issue Type: New Feature
>> � � � � Components: Cayenne Core Library
>> � � � � � Reporter: Evgeny Ryabitskiy
>> � � � � � �Fix For: 3.1M1
>>
>>
>> Duplication from Dev-list:
>>
>> So.. I have several modules, each has own DomainConfig file and
>> connection to it's DataBase. Sometimes there can be used different DB
>> servers and even different DB types (usually it's Oracle and MS SQL,
>> sometimes Sybase).
>>
>> Singletons:
>> 1) Configuration.getSharedConfiguration()
>> This problem is solved:
>> DefaultConfiguration conf = new
>> DefaultConfiguration("module1-cayenne.xml");
>> conf .initialize;
>> conf.getDomain();
>> //spend some time to find solution... everywhere examples with
>> SharedConfiguration
>>
>> 2)DataContext.getThreadLocal()
>> Solved by own ThreadLocal for each module. (modules can work in one
>> thread)
>> //also spend some time
>>
>> 3)Transaction.getThreadTransaction()
>> this is killing one!!!
>> using of own ThreadLocal doesn't help.
>> It's hard-coded in performing Query to use this singleton
>> Transaction.getThreadTransaction()
>> And that is really huge problem for me.
>>
>> So me suggestion is to move this ThreadLocal to DataDomain. Still can
>> use singleton API for standalone applications.
>> Also we can move DataContext to DataDomain.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>
>

Re: Singletons in Cayenne and problems. Can I use multiple transactions?

2009-12-01T13:27:55Z

Problem in multiple Domains.
When I am creating transaction I am creating it's for specific
DataDomain (like a DataContext).
When I have 2 Modules with dedicated DataDomains (so it will be 2
DataDomains) I can create 2 Transactions
(domain.createTransaction()).

But to thread I can bind only one. Then when I start performing queries I got:
1)First Domain Transaction is binded and handled normally
2)Second Domain Transaction is override by first DataDomain. So when I
perform query for second: ThreadLocals return Transaction for firs
Domain.

Evgeny



2009/12/1 Andrus Adamchik :
> Singletons are bad in a general purpose framework, like Cayenne. No question
> about that. Per your description even thread-local singletons can be a
> problem, which is less obvious to me, but I guess real in some
> circumstances. So let's see what those are.
>
>> 2)DataContext.getThreadLocal()
>> Solved by own ThreadLocal for each module. (modules can work in one
>> thread)
>> //also spend some time
>
> This is just a convenience in Cayenne. Nobody's forced to use it. I will go
> as far as to suggest to remove it from Cayenne 3.1 as a built-in feature,
> and just document it as a possible design pattern in a user application.
>
>> 3)Transaction.getThreadTransaction()
>> this is killing one!!!
>> using of own ThreadLocal doesn't help.
>> It's hard-coded in performing Query to use this singleton
>> Transaction.getThreadTransaction()
>> And that is really huge problem for me.
>
> J2EE pattern of tying a transaction to an execution thread, even if multiple
> data sources are involved, makes sense as it allows to commit/rollback
> multiple things at once. Cayenne Transaction sort of follows that. JDBC
> connections within the transaction are scoped by DataNode name. So what
> exactly is the problem?
>
> Andrus
>
>
>
> On Dec 1, 2009, at 2:44 PM, Evgeny Ryabitskiy wrote:
>
>> Hello 2 everyone!
>>
>> Today I one more time thinking about singleton pattern and it's hard
>> usssage in Cayenne.
>>
>> So.. I have several modules, each has own DomainConfig file and
>> connection to it's DataBase. Sometimes there can be used different DB
>> servers and even different DB types (usually it's Oracle and MS SQL,
>> sometimes Sybase).
>>
>> Singletons:
>> 1) Configuration.getSharedConfiguration()
>> This problem is solved:
>> DefaultConfiguration conf = new
>> DefaultConfiguration("module1-cayenne.xml");
>> conf .initialize;
>> conf.getDomain();
>> //spend some time to find solution... everywhere examples with
>> SharedConfiguration
>>
>> 2)DataContext.getThreadLocal()
>> Solved by own ThreadLocal for each module. (modules can work in one
>> thread)
>> //also spend some time
>>
>> 3)Transaction.getThreadTransaction()
>> this is killing one!!!
>> using of own ThreadLocal doesn't help.
>> It's hard-coded in performing Query to use this singleton
>> Transaction.getThreadTransaction()
>> And that is really huge problem for me.
>>
>> So me suggestion is to move this ThreadLocal to DataDomain. Still can
>> use singleton API for standalone applications.
>> Also we can move DataContext to DataDomain.
>>
>> Evgeny.
>>
>
>