Re: Cayenne geospacial features
Hello.
With Cayenne, you can easily create a ExtendedType that convert JTS geometries
on the java side to Well-Known Binary on the database side. I did create a
similar ExtendedType to create JTS geometries to Well-Known Text for storing
JTS geometries as text (se below). We have used this in production for several
years. For PostGIS, I have not used Cayenne on the geometries, but it should
work identical.
A long time ago, I wrote about this over at
http://objectstyle.org/confluence/display/CAY/Mapping+JTS+Geometries , but that
website does not exist anymore.
Next up is PostGIS queries. PostGIS queries are very powerful, but the syntax
can be quite strange. SQLTemplate or something similar should work fine. I have
some simple application specific java abstraction to the most common stuff like
ST_Intersects to fetch rows matching a tile and such.
For related libraries, JTS has lots of geometry goodies. It is in the middle of
a move with package name switch. The old one from vividsolutions is most
compatible with other libraries for now. Geotools has lots of goodies for
projection and such. And perhaps our library,
https://github.com/ElectronicChartCentre/java-vector-tile , for constructing
Mapbox Vector Tiles from java for use in Mapbox GL JS or Native.
Regards,
Tore Halset.
/**
* An ExtendedType that can be used by cayenne to covert WKT to/from JTS
* Geometry - com.vividsolutions.jts.geom.Geometry
*/
public class WKTGeometryType implements ExtendedType {
private static final String CHARSET = "UTF-8";
private Class geometryClass;
public WKTGeometryType(Class geometryClass) {
this.geometryClass = geometryClass;
}
public String getClassName() {
return geometryClass.getName();
}
public boolean validateProperty(Object source, String property, Object
value,
DbAttribute dbAttribute, ValidationResult validationResult) {
Geometry g = (Geometry) value;
if (!g.isValid()) {
String msg = "Invalid geometry";
validationResult.addFailure(new BeanValidationFailure(source,
property, msg));
return false;
}
return true;
}
public void setJdbcObject(PreparedStatement statement, Object value, int
pos, int type,
int precision) throws Exception {
Geometry g = (Geometry) value;
switch (type) {
case Types.BLOB:
statement.setBytes(pos, g.toText().getBytes(CHARSET));
break;
default:
statement.setString(pos, g.toText());
break;
}
}
public Object materializeObject(ResultSet rs, int index, int type) throws
Exception {
String wkt = null;
switch (type) {
case Types.BLOB:
wkt = new String(rs.getBytes(index), CHARSET);
break;
default:
wkt = rs.getString(index);
break;
}
if (wkt == null) {
return (Geometry) null;
}
return new WKTReader(new GeometryFactory()).read(wkt);
}
public Object materializeObject(CallableStatement rs, int index, int type)
throws Exception {
String wkt = null;
switch (type) {
case Types.BLOB:
wkt = new String(rs.getBytes(index), CHARSET);
break;
default:
wkt = rs.getString(index);
break;
}
if (wkt == null) {
return (Geometry) null;
}
return new WKTReader(new GeometryFactory()).read(wkt);
}
}
> On 21 Jan 2019, at 08:11, Nikita Timofeev wrote:
>
> Hi All,
>
> I had an interesting discussion with my colleagues who use PostGIS and
> they are really interested in better support from Cayenne. Well,
> actually they can’t use Cayenne on that project, as it will be like
> using just raw SQL.
>
> So I was wondering if anyone else actively uses spacial features and
> can help to determine missing parts in Cayenne. Maybe we can push this
> forward and get some really nice cayenne-spacial module.
>
> Any feedback is welcome.
>
> --
> Best regards,
> Nikita Timofeev
>
Re: java/jdbc version
Hello. > On 04 Sep 2015, at 09:53, Andrus Adamchik <and...@objectstyle.org> wrote: > > Hi Tore, > >> cayenne 4 is java 6. Will it go java 7+ or are we staying on 6? I want to >> use the new java.sql.Connection#getSchema. It will probably require updated >> jdbc drivers and dbcp2 as well, so it might be easier to create our own >> adapter#getSchema(Connection). What do you think? > > I've been softly advocating to switch to Java 7 in 4.0 for some time. And I > think by now just enough time has passed to consider Java 6 a distant > memory. > > IIRC Savva either started working or was planning to start working on a DBCP2 > module, so we should be covered on that front as well. > > So maybe we take an (informal?) vote on this and go Java 7? +1 Good news. All our stuff use java 8 now. >> One more thing, is it okay to send in github pull-requests now or should I >> push to the actual branch at apache? > > If you want your code to be reviewed before commit, then pull request on > GitHub is the way to go. If not, you can just commit it to the ASF repo's > master. Thanks. That is perfect. Regards, Tore Halset.
java/jdbc version
Hello. I am trying to solve https://issues.apache.org/jira/browse/CAY-2024 cayenne 4 is java 6. Will it go java 7+ or are we staying on 6? I want to use the new java.sql.Connection#getSchema. It will probably require updated jdbc drivers and dbcp2 as well, so it might be easier to create our own adapter#getSchema(Connection). What do you think? One more thing, is it okay to send in github pull-requests now or should I push to the actual branch at apache? Regards, Tore Halset.
Re: Soliciting Cayenne success stories
Hello Andrus. We (Electronic Chart Centre and PRIMAR) use Cayenne in our system to collect, quality control and distribute world coverage nautical charts to navies, pilots, inspectors and several thousand vessels. We have been happy users of Cayenne since 2005 and are now on version 3.1. https://www.primar.org https://www.ecc.no Regards, Tore Halset. On 06 Sep 2014, at 14:40, Andrus Adamchik and...@objectstyle.org wrote: Sorry for cross-post. With release 3.1-final approaching, I'd like to ask our community for Cayenne success stories. We'd like to promote the project, and the best way is to show how it is used in real life. NHL, ish, Nike are all actively using Cayenne in their major products - that I am well aware of. Apple used it (or is using it?). But who else? If you don't mind sharing your story, please email me directly or post it on the list. Even if you are already on our success stories page and/or a long-term committer, still ping me. We haven't updated our list in a while. Lost of new things have happened. So some recent information on your latest Cayenne projects would be great. Thanks in advance, Andrus
Re: [VOTE] Cayenne 3.2M1 release
+1 I have downloaded cayenne-3.2M1-macosx.dmg, used the modeler and ran all of our unit- and integration tests using cayenne-server-3.2M1.jar. My notes: * Cayenne Modeler found a duplicate db-relationship in our model that we have not gotten a report on earlier (3.1 snapshot from october last year). Good! * Had to do obj.getObjEntity() - Cayenne.getObjEntity(obj) a couple of places. Nice work guys! Regards, Tore Halset. On 28. juni 2013, at 02:42, Andrus Adamchik and...@objectstyle.org wrote: Release artifacts are ready: 1. Assemblies: http://people.apache.org/~aadamchik/release/3.2M1/ 2. Maven: https://repository.apache.org/content/repositories/orgapachecayenne-083/ Please check it out and cast your votes. Thanks, Andrus
Re: [VOTE] 3.1B2
+1 examined the mac bundle, run it with the test suite for our cayenne-based product. We are already using almost the same (up to and including CAY-1741) in production. Regards, Tore. On 7. feb. 2013, at 20:15, Andrus Adamchik and...@objectstyle.org wrote: So, the second Beta is ready and can be found at [1] in its Maven form and at [2] as source and binary assemblies. Please evaluate the release and cast your votes. Since the docs are still work in progress, I decided not to make it an RC release, but I think we are getting there. Thanks, Andrus [1] https://repository.apache.org/content/repositories/orgapachecayenne-200/ [2] http://people.apache.org/~aadamchik/release/3.1B2/
Re: A new twitter icon
Thanks :) Kinda my signature skiing hat :) - Tore. On 7. des. 2012, at 03:49, Michael Gentry mgen...@masslight.net wrote: Looks nice, but Tore's hat is equally impressive. :-) mrg On Thu, Dec 6, 2012 at 10:22 AM, Andrus Adamchik and...@objectstyle.orgwrote: https://twitter.com/ApacheCayenne
Re: Moving merge package to cayenne-tools in 3.2?
Hello. We use the merge package in our web applications during startup to perform some not-destructive database migration. Like adding fields, expanding fields and so on. This makes database migration a lot easier for us since most of it is done automatically. For us, this is more useful than having merge in the modeler. However, if it is in a separate jar or not is not important. Regards, Tore Halset. On Nov 10, 2012, at 5:14 PM, Andrus Adamchik and...@objectstyle.org wrote: I wonder we should move merge package to cayenne-tools from cayenne-server in 3.2. To me schema manipulation operations are somewhat separate from the runtime part. (So DbLoader and DbGenerator are also candidates for a similar move, maybe later). merge main use seems to be from the Modeler, which imports cayenne-tools.jar. And of course cayenne-tools is available via Maven, and other Cayenne distribution channels. Any reason to keep it in the runtime framework? Andrus P.S. I am also looking at much more glaring modularity issues with Cayenne (the whole unpublished thing that we discussed on many occasions), but don't have any proposals yet, so figured we'd start with things more confined in scope.
Re: [jira] [Closed] (CAY-1741) serializable DataObjectBaseProperty
Thanks for the push, I have committed tests now. Regards, Tore Halset. On Oct 3, 2012, at 4:03 PM, John Huss johnth...@gmail.com wrote: Are there unit tests for this - serialization? Without tests, this is almost certain to be broken again in the future. On Wed, Oct 3, 2012 at 8:56 AM, Tore Halset (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/CAY-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Tore Halset closed CAY-1741. Resolution: Fixed serializable DataObjectBaseProperty --- Key: CAY-1741 URL: https://issues.apache.org/jira/browse/CAY-1741 Project: Cayenne Issue Type: Bug Components: Core Library Affects Versions: 3.1B1, 3.2M1 Reporter: Tore Halset Assignee: Tore Halset Priority: Minor Fix For: 3.1B2, 3.2M1 Doing session persistence and got an error message stating that org.apache.cayenne.reflect.generic.DataObjectAttributeProperty is not serializable. Fixing this in superclass DataObjectBaseProperty instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (CAY-1688) [PATCH] rename DataDomain.getNode to getDataNode
Hi. Okay, that is fine. I deleted the comment. - Tore. On Aug 23, 2012, at 11:05 , Andrus Adamchik wrote: Hi Tore, Trunk is 3.2 which will presumably be released in more than a year, so all the previously deprecated stuff was removed on trunk per CAY-1718. This is consistent with our past deprecation policies. But we can discuss a change to that. Andrus On Aug 23, 2012, at 11:51 AM, Tore Halset (JIRA) wrote: [ https://issues.apache.org/jira/browse/CAY-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13440139#comment-13440139 ] Tore Halset commented on CAY-1688: -- The old getNode is gone in trunk and getNodeName was added in 3.1. Could we keep getNode (as deprecated) a bit longer? Just to make it a bit simpler going back/forward between cayenne versions. [PATCH] rename DataDomain.getNode to getDataNode Key: CAY-1688 URL: https://issues.apache.org/jira/browse/CAY-1688 Project: Cayenne Issue Type: Improvement Components: Core Library Affects Versions: 3.1M3 Reporter: John Huss Priority: Trivial Labels: patch Fix For: 3.1B1 Attachments: getDataNode_patch.txt Original Estimate: 10m Remaining Estimate: 10m DataDomain.getNode(String nodeName) should be called getDataNode instead for better consistency and discoverability. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Non-blocking DataRowStore - need help to test
Wow, thanks a lot! Looking forward to test and use this! - Tore. On Feb 22, 2012, at 19:54, Andrus Adamchik and...@objectstyle.org wrote: Here is a potentially disruptive change to Cayenne core: http://svn.apache.org/viewvc?view=revisionrevision=1292437 (also see https://issues.apache.org/jira/browse/CAY-1670 ) This removes the major global lock and has a potential to significantly increase throughput (which is an issue, see CAY-1124 by Tore for instance). The implementation is based on a previously untried by us data structure - ConcurrentLinkedHashMap - http://code.google.com/p/concurrentlinkedhashmap/ . It is used by Apache Cassandra, so presumably it works and can handle the load. I internalized this code, placing it under org.apache.cayenne.util.concurrentlinkedhashmap. I need help with testing though... Maybe someone has any kind of load tests that can emulate multiple DataContexts attached to a single ServerRuntime and performing various select/modify operations? Or maybe you are daring enough to place this in production? I will do the same on my end. To give some reassurance, our single-threaded unit tests pass 100% with no changes after I swapped commons-collections LRUMap to ConcurrentLinkedHashMap. Appreciate feedback on this feature! Thanks, Andrus
Re: [VOTE] Cayenne 3.1M3
+1 Works great with our test suite. Also tested (Mac)modeler, who found a bad relationship not found before. Good. ObjectContexts deleteObject is now deprecated. deleteObjects with varargs could be named just delete to be grammatically correct both for 1 and 1 arguments. Thanks for the great work! Tore. On Sep 13, 2011, at 21:55, Andrus Adamchik and...@objectstyle.org wrote: So we have this: http://people.apache.org/~aadamchik/release/3.1M3/ and we have this (a new addition to our release process) : https://repository.apache.org/content/repositories/orgapachecayenne-052/ and we haven't released 3.1 milestones since February, which is a shame, considering a quick pace of development :-) Andrus
Re: M3?
Hello. Should CAY-1567 be on the list as well? I think you fixed it. - Tore. On Jul 13, 2011, at 19:35 , Andrus Adamchik wrote: I am going to post M3 artifacts for vote soon. As an M2 user, I need CAY-1526 fix (see a list of closed jiras below), and we also have one new major feature to show - CAY-943. Plus as usual a number of other cool things. If there are no objections, I'll try to get it together around this weekend. Cheers, Andrus Changes/New Features Since 3.1M2: CAY-943 Support multiple cayenne.xml files in the project CAY-1461 CayenneModeler: remove ScopeMVC dependency - ObjRelationshipInfoDialog CAY-1556 Add path construction feature to make constructing paths from constants easier for queries and orderings CAY-1525 CharType: don't trim spaces on the left CAY-1544 Remove jdk1.6 module from Cayenne sources CAY-1545 cayenne-lifecycle Referenceable handler refactoring CAY-1547 cayenne-lifecycle: support for setting UuidRelationships CAY-1549 Migrate BatchQueryBuilderFactory to DI CAY-1553 cayenne-lifecycle: @SortWeight annotation CAY-1573 QueryLogger to DI JdbcEventLogger migration CAY-1584 Improve Cayenne modeler re-ordering named query in the cayenne map xml Bug Fixes Since 3.1M2: CAY-1526 Preferences: java.lang.IllegalArgumentException: Key too long CAY-1546 cayenne-lifecycle: UuidBatchFault concurrency issues CAY-1555 Unpublished dependencies of Maven plugins CAY-1575 Error generating Embeddable classes in Cayenne Modeler CAY-1577 SQL queries for LIKE expressions with escape character generated with syntax errors CAY-1581 Not-Escaping during serialization to *.map.xml CAY-1585 SelectQuery automatic cache key needs FetchOffset
Re: M3?
Okay. Understad. On 14. juli 2011, at 16.28, Andrus Adamchik wrote: It was recorded under 3.0.2 (I guess we may need to enter closed Jiras twice for parallel branches. Right now we implicitly assume that anything fixed on the stable branch is automatically available on trunk). Andrus On Jul 14, 2011, at 4:38 PM, Tore Halset wrote: Hello. Should CAY-1567 be on the list as well? I think you fixed it. - Tore. On Jul 13, 2011, at 19:35 , Andrus Adamchik wrote: I am going to post M3 artifacts for vote soon. As an M2 user, I need CAY-1526 fix (see a list of closed jiras below), and we also have one new major feature to show - CAY-943. Plus as usual a number of other cool things. If there are no objections, I'll try to get it together around this weekend. Cheers, Andrus Changes/New Features Since 3.1M2: CAY-943 Support multiple cayenne.xml files in the project CAY-1461 CayenneModeler: remove ScopeMVC dependency - ObjRelationshipInfoDialog CAY-1556 Add path construction feature to make constructing paths from constants easier for queries and orderings CAY-1525 CharType: don't trim spaces on the left CAY-1544 Remove jdk1.6 module from Cayenne sources CAY-1545 cayenne-lifecycle Referenceable handler refactoring CAY-1547 cayenne-lifecycle: support for setting UuidRelationships CAY-1549 Migrate BatchQueryBuilderFactory to DI CAY-1553 cayenne-lifecycle: @SortWeight annotation CAY-1573 QueryLogger to DI JdbcEventLogger migration CAY-1584 Improve Cayenne modeler re-ordering named query in the cayenne map xml Bug Fixes Since 3.1M2: CAY-1526 Preferences: java.lang.IllegalArgumentException: Key too long CAY-1546 cayenne-lifecycle: UuidBatchFault concurrency issues CAY-1555 Unpublished dependencies of Maven plugins CAY-1575 Error generating Embeddable classes in Cayenne Modeler CAY-1577 SQL queries for LIKE expressions with escape character generated with syntax errors CAY-1581 Not-Escaping during serialization to *.map.xml CAY-1585 SelectQuery automatic cache key needs FetchOffset
Re: query cloneViaSerialization
Wow, thanks! On May 15, 2011, at 12:01, Andrus Adamchik and...@objectstyle.org wrote: On May 11, 2011, at 1:35 AM, Andrus Adamchik wrote: I guess that makes 'cloneViaSerialization' unusable for Cayenne stack classes. Specifically we should rewrite BaseQueryMetadata.setPrefetchTree(..) to clone PrefetchTreeNode manually, which should be pretty trivial. BTW just committed this fix to trunk. (should've opened a Jira I guess). Andrus
Re: Java 6 for 3.1?
+1 On Jan 28, 2011, at 14:36, Andrus Adamchik and...@objectstyle.org wrote: Since Java 5 has been EOL'd for some time, and Java 7 seems to be close to GA, (and there's no more Java 5 on OS X, so I've no idea whether Cayenne is really java 5 compatible :-)), how about we make Java 6 a minimal JVM requirement for Cayenne 3.1? Keeping things tight and all that. Comments? Andrus
Re: [VOTE] cayenne-3.1M1
+1 Downloaded, tested in our system. Here are the things I had to change in our system: * Upgraded my own DataSourceFactory implementation. Now even simpler than before. * Switching to ServerRuntime runtime = new ServerRuntime(cayenne-mydomain.xml);. Nice! * One of our CayenneDataObject subclasses had a custom equals(Object) method that did not check for the class type. This caused a ClassCastException during a commitChanges of some deletes. Not a problem since this was a bug in our code. Here is the stacktrace: java.lang.ClassCastException: data.Y cannot be cast to data.X at data.X.equals(X.java:144) at java.util.ArrayList.remove(ArrayList.java:423) at org.apache.cayenne.DataChannelSyncCallbackAction.nodeRemoved(DataChannelSyncCallbackAction.java:122) at org.apache.cayenne.graph.NodeDeleteOperation.apply(NodeDeleteOperation.java:37) at org.apache.cayenne.graph.CompoundDiff.apply(CompoundDiff.java:91) at org.apache.cayenne.access.ObjectStoreGraphDiff.apply(ObjectStoreGraphDiff.java:134) at org.apache.cayenne.DataChannelSyncCallbackAction.init(DataChannelSyncCallbackAction.java:74) at org.apache.cayenne.DataChannelSyncCallbackAction$FlushCallbackAction.init(DataChannelSyncCallbackAction.java:173) at org.apache.cayenne.DataChannelSyncCallbackAction.getCallbackAction(DataChannelSyncCallbackAction.java:51) at org.apache.cayenne.access.DataDomain.onSync(DataDomain.java:749) at org.apache.cayenne.access.DataContext.flushToParent(DataContext.java:850) at org.apache.cayenne.access.DataContext.commitChanges(DataContext.java:789) Regards, - Tore. On 17. nov. 2010, at 20.21, Andrus Adamchik wrote: http://people.apache.org/~aadamchik/release/3.1M1/
M1 Configuration
Hello. I am trying out the new M1 candidate. Upgrading from 3.0.1 this got me to a compile error since org.apache.cayenne.conf.Configuration does not exist any more. Is okay to remove this in 3.1 when it was not deprecated in 3.0.1? What should I use instead of Configuration.getSharedConfiguration().getDomain() to get to the DataDomain? - Tore.
Re: [VOTE] 3.0.1 - reloaded
Hello. +1 I have done: * a brief check of licensing files/headers. * junit-tested the distribution with our own system. * done some basic testing of the modeler user interface. This is probably way too brief compared to the PMC requirements discussed earlier. Regards, - Tore. On Aug 26, 2010, at 09:00 , Andrus Adamchik wrote: http://people.apache.org/~aadamchik/release/3.0.1_2/ So here is a new set of 3.0.1 release files, with a source file, and binary files built from that source (and not from SVN or git). The only noteable difference is that there's no src folder in the binary distros, making them ~2M smaller. NOTICE file was fixed as well. Please evaluate and cast your votes. Andrus
Re: [VOTE] Cayenne Release 3.0RC3
+1 On 29. mars 2010, at 15.21, Andrus Adamchik wrote: Just posted new RC3 artifacts: http://people.apache.org/~aadamchik/release/3.0RC3/ Please evaluate and cast your votes. As a reminder, the plan for RC3 once it is released, is to wait for some time to get user feedback, and barring any new serious bugs, clone it to make 3.0 final. Andrus
Re: [jira] Commented: (CAY-1354) Wrong Types mapping for selected values in Row Queries
This is an old-timer. Did you do a createlang plpgsql databasename? - Tore. On Jan 13, 2010, at 07:54 , Рябицкий Евгений wrote: 13.01.2010 9:52:17 org.apache.cayenne.unit.CayenneResources getResources SEVERE: Error generating schema... org.postgresql.util.PSQLException: ERROR: language plpgsql does not exist
Re: Hudson test against MS SQL server
This is so great! Perhaps jtds can be fetched via maven? - Tore. On Jan 8, 2010, at 01:01 , Aristedes Maniatis wrote: Thanks to the hard work of Tim Ellison, we now have MS SQL server installed in the Hudson cloud. Andrus, since you now have access to all the Hudson slaves (I only have the master), could you update the connection.properties on all of them to add the new MS SQL database we can run tests against. I'll send you user/pass when I get them. I guess we'll also need to install the jdbc drivers everywhere (I'm sure maven can't pull them down). Ari -- -- Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
3.0 - 3.1 experience
Hello. I wanted to test my project with some stuff in svn trunk aka cayenne 3.1. As I have not been a good guy and fixed all the deprecated warnings in my project, I had some work to do in my code to get it to work with 3.1 Here are a list of the things I had to change. The first item gave me a lot of work, the others was not a big deal. After the upgrade from 3.0 to 3.1, I got around 200 compile errors to fix in one project.. * Ordering.DESC/ASC and even false/true - SortOrder.DESCENDING/ASCENDING * context.refetchObject() * context.createAndRegisterNewObject - context.newObject * dataObject.getDataContext() - getObjectContext() Btw, great work on the RC! Regards, - Tore.
Re: DO/PO design
Hello. Would it be possible to have attributes within an entity as enum and then use EnumMap? It uses an array for storage, so it does not need the buly Map.Entry objects used in a normal HashMap. - Tore. On Nov 30, 2009, at 11:09 , Andrus Adamchik wrote: Another possible lightweight design that would allow to reconcile DO's and PO's is to use Object[] instead of either HashMap or ivars to store values, with indexes in array corresponding to ObjAttribute names sorted in alphabetic order. Will probably have its own quirks I guess (e.g. how do we define the array size for a generic object that can be mapped to different entities), however it has some serious benefits: * memory use very close to ivars * access speed very close to ivars * can be used with Faults * can be used with generic objects Andrus On Nov 24, 2009, at 9:47 PM, Andrus Adamchik wrote: True, but they are still user facing collections (or more generally valueholders, as this also works for to-one), that get inflated internally as needed. DO faults are singletons of this type: http://cayenne.apache.org/doc/api/org/apache/cayenne/Fault.html So PO lazy relationship resolving goes like this: 1. on select, init lazy property with a hollow ValueHolder 2. on ValueHolder value access, inflate ValueHolder with the DB data For DO it has an extra step: 1. on select, init lazy property with a singleton Fault of a type corresponding to the relationship semantics 2. on property access, *replace* Fault with either a hollow collection or a target DO (which can be hollow or resolved from cache) 3. on collection or hollow DO value access, inflate them. The difference may be subtle, but still essential. First, in DO case there's no to-one ValueHolder. Target object is attached directly. Also the user never sees the Fault object itself, so we can replace it with another object when needed. Among other things this allows a major memory optimization, as Fault instances are singletons shared by all DOs. So all in all, DO design seems more sound (and quite possibly that whatever memory we save on using ivars in PO, is getting lost to extra and more eager ValueHolders). Andrus On Nov 24, 2009, at 9:28 PM, Andrey Razumovsky wrote: Actually, I don't understand :) PO arc properties are all faults (classes PersistentObject*) 2009/11/24 Andrus Adamchik and...@objectstyle.org On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote: So ... another attempt at abstract analysis (or an attempt at unwinding my memory...) IIRC the main difference between DO and PO is fault handling - we can store a Fault instance in a map, but not in a typed ivar. So PO's have no concepts of faults at all, and the lifecycle is different. DO approach is more lazy (it won't try to create even a placeholder collection until the property is accessed), and I prefer it to PO's. Wonder if when we reconcile that somehow, the rest will fall into place on its own?? (E.g. for PO's, we generate extra boolean fault properties for each relationship, that are checked on every property access?) Nice idea, need to think about it. But anyways, this is separate task May or may not be a separate task. But definitely bigger in scope. Andrus -- Andrey
Re: [VOTE] Apache Cayenne release 3.0B1
Hello. I have tested it with our internal application junit test suite on PostgreSQL, Derby and MS SQL Server. No problems found. I have also done some testing of the modeler. As I have used the modeler with earlier 3.0 versions, the upgrade-project message was a bit strange. Project needs an upgrade to a newer version. Older Project Version Detected: 3.0. Upgrade? 3.0 is not such an old version.. I have read the separate thread regarding this issue. So, my vote is: +1 - Tore. On Oct 25, 2009, at 17:49 , Andrus Adamchik wrote: Release artifacts are posted here: http://people.apache.org/~aadamchik/release/3.0B1/ Please evaluate and cast your votes. Cheers, Andrus
Re: SchemaUpdateStrategy
Hello. Okay, I understand. We all have different setups and needs. I am creating all the tokens and filter by type. I plan to clean up this by adding a method named something like mayRemoveInformation() to all the tokens. The startup merge (step 1 including metadata fetching and issuing of tokens) is done in 6 seconds on PostgreSQL with ~90 tables, so I have not bothered optimizing. A little bit slower with Derby. For my setup, filtering out extra tables is not important. To speed up junit tests, I implemented support for this in DbMerger. You just override the includeTableName-method. Regards, - Tore. On Jun 10, 2009, at 15:32 , Andrus Adamchik wrote: Hi Tore, We definitely looked at DbMerger, but for the implementation it was decided to go a parallel way, essentially because most strategies are using a much smaller subset of JDBC metadata operations for its schema analysis, and the analysis flow needed to be flexible. E.g. we don't care if there are extra tables in the DB, and we don't want to fetch the columns for those. Attribute rules checking is fairly lax (null/not null mismatch is ignored). All or nothing strategies would abort out early if they detect a certain single object presence/absence. Things like that, all affecting application startup speed (not only on Oracle). Finally we decided against including a partial update strategy for the reasons we discussed before - production schema upgrade may require data migration, something the strategy won't know anything about. So essentially the conclusion was that the main strength of DbMerger wasn't applicable for the problem at hand. Users can still implement such strategy. With the help of DbMerger it will be trivial indeed. I am open to reconciling the two, just thought that it will be too invasive on the DbMerger end. So is there optimized API for Step #1, or does it still get all tokens with DbLoader, and then throws away unsafe ones? Andrus
SchemaUpdateStrategy
Hello. I just took a look at this new feature for the first time. It is nice to be able to set a SchemaUpdateStrategy in the model. From my perspective, it is a little strange that this functionality is not based on the DbMerger. There is one hint to the reason for this in CAY-1193: This version non use DBMerger for ThrowOnPartialSchemaStrategy and ThrowOnPartialOrCreateSchemaStrategy. In this strategy used new StrategyAnalyser, which can speed up implementation in oracle. If StrategyAnalyser is faster than DbMerger on oracle, is it possible to make DbMerger faster as well? I do not have access to Oracle, and know metadata fetching in Oracle is super slow. Is it ok if I create a new SchemaUpdateStrategy that use the DbMerger? It will be a safe version that only adds tables and columns, not remove them. And expand, but not shrink column length. Some people are already using DbMerger for auto-upgrade during startup. I do this in 3 steps. The first step could fit in a SchemaUpdateStrategy. 1. Use DbMerger and issue all the safe tokens. That is all tokens that does not remove information. 2. Use cayenne code to fill/update content of database. This is application specific. 3. Offer the user to clean up the database using all the unsafe tokens that typically remove columns and so on. Regards, - Tore.
Re: Modeling indexes
On Jun 4, 2009, at 1:16 , Zissis Trabaris wrote: Is there a MergerToken or equivalent that I can use to define indexes on tables? Not yet, but I need this as well. We will first have to make support for defining (db-)indexes in the model and then create MergerTokens to add/delete indexes. I will work on this if no one else does, but not yet. Patches are welcome as always! Regards, - Tore.
Re: [VOTE] Cayenne 3.0M6
Hello. +1 What I did: * Downloaded the mac version and used the modeler. * Tested with our (company) junit tests for Derby and PostgreSQL. Regards, - Tore. On 18. mai. 2009, at 09.45, Andrus Adamchik wrote: M6 release artifacts are posted here: http://people.apache.org/~aadamchik/release/3.0M6/ Please evaluate and cats your vote. Here is my unit testing results: HSQLDB [passed] PostgreSQL [passed] H2 [passed] SQLServer [passed] MySQL Failed tests: test(org.apache.cayenne.merge.SetAllowNullToDbTest) Oracle Failed tests: testPerformQueryInheritanceSuper (org.apache.cayenne.CayenneContextInheritanceTest) test(org.apache.cayenne.merge.SetNotNullToDbTest) testAddAndDropColumnToDb(org.apache.cayenne.merge.MergerFactoryTest) testChangeVarcharSizeToDb(org.apache.cayenne.merge.MergerFactoryTest) testMultipleTokensToDb(org.apache.cayenne.merge.MergerFactoryTest) test(org.apache.cayenne.merge.ValueForNullTest) test(org.apache.cayenne.merge.SetAllowNullToDbTest) testDBGeneratorStrategy (org.apache.cayenne.access.dbsync.SchemaUpdateStrategyTest) testMixedStrategyTableNoExist (org.apache.cayenne.access.dbsync.SchemaUpdateStrategyTest) Derby Tests in error: testDifferentEntity (org.apache.cayenne.access.DataContextEJBQLSubqueryTest) testExists(org.apache.cayenne.access.DataContextEJBQLSubqueryTest) testAddTable(org.apache.cayenne.merge.CreateTableToModelTest) Andrus
Re: 3.0M6 testing
On May 18, 2009, at 14:15 , Andrus Adamchik wrote: On May 18, 2009, at 2:02 PM, Tore Halset wrote: mvn mvn -Dcayenne.test.connection=derby Thanks. I have fixed the derby issue in trunk. Should I commit it to the tag as well? - Tore.
MapEvent
Hello. Looking at CAY-1169. I need some way to refresh the view. After browsing the code it looks like this should be done by sending MapEvents to the ProjectController. None of the ToModel merge tokens does this now. The problem is that the ProjectController is in the modeler project, but all the merge tokens exist in the core project. One option could be to extract the fire-methods of ProjectController to a interface named MapEventConsumer in the core? Or could this interface be simplified by just having a fireMapEvent-method that does lots of instanceof checks and call the correct fire-method.. What do you guys think of all this? https://issues.apache.org/jira/browse/CAY-1169 - Tore.
oracle Re: 3.0M6 testing
On 18. mai. 2009, at 14.17, Andrus Adamchik wrote: On May 18, 2009, at 2:02 PM, Tore Halset wrote: I would love to fix the oracle issues with merging, but I do not have access to an oracle instance. Last time I tried, it was a lot of work to install oracle on any of the systems I work on - mac and ubuntu linux. Perhaps I should start up one of the images from oracle on Amazon EC2. Or perhaps they will bundle it for free with the next java install :) I installed a Linux Parallels virtual share on my MacBook and put Oracle on it. The installation itself is a bit convoluted, but at the end it worked. It looks like Oracle now has a downloadable version for Mac OS X. I have not gotten it to work yet. http://www.oracle.com/technology/tech/macos/index.html - Tore.
Re: 3.0M6 testing
Hello. I am not able to reproduce the derby issues in cayenne trunk. Do you have an old derby version or am I doing something wrong. svn update mvn clean cd framework/cayenne-jdk1.5-unpublished mvn grep FAIL target/surefire-reports/*.txt I would love to fix the oracle issues with merging, but I do not have access to an oracle instance. Last time I tried, it was a lot of work to install oracle on any of the systems I work on - mac and ubuntu linux. Perhaps I should start up one of the images from oracle on Amazon EC2. Or perhaps they will bundle it for free with the next java install :) Could we set up hudson to do testing on all the databases we support? I know it will be a lot of work, but will it be accepted by apache infra? We use hudson to test all of our internal stuff on both PostgreSQL and Derby. - Tore. On May 17, 2009, at 18:38 , Andrus Adamchik wrote: I created the tag, so unstable code checkins can resume on trunk now. Haven't created the artifacts yet, until we fix some of the unit test failures below. Specifically looks like there are some new problems with MySQL that I would like to fix before moving forward. Will be investigating this now. Andrus Unit testing results of the M6 tag: HSQLDB [passed] PostgreSQL [passed] H2 [passed] SQLServer [passed] Derby (same errors as we had in M5) testDifferentEntity (org.apache.cayenne.access.DataContextEJBQLSubqueryTest) testExists(org.apache.cayenne.access.DataContextEJBQLSubqueryTest) testAddTable(org.apache.cayenne.merge.CreateTableToModelTest) Oracle Failed tests: testPerformQueryInheritanceSuper (org.apache.cayenne.CayenneContextInheritanceTest) test(org.apache.cayenne.merge.SetNotNullToDbTest) testAddAndDropColumnToDb(org.apache.cayenne.merge.MergerFactoryTest) testChangeVarcharSizeToDb(org.apache.cayenne.merge.MergerFactoryTest) testMultipleTokensToDb(org.apache.cayenne.merge.MergerFactoryTest) test(org.apache.cayenne.merge.ValueForNullTest) test(org.apache.cayenne.merge.SetAllowNullToDbTest) testDBGeneratorStrategy (org.apache.cayenne.access.dbsync.SchemaUpdateStrategyTest) testMixedStrategyTableNoExist (org.apache.cayenne.access.dbsync.SchemaUpdateStrategyTest) MySQL test(org.apache.cayenne.merge.SetAllowNullToDbTest) testUpdateQualifier (org.apache.cayenne.access.DataContextEJBQLUpdateTest) testUpdateNoQualifierString (org.apache.cayenne.access.DataContextEJBQLUpdateTest) testUpdateNoQualifierNull (org.apache.cayenne.access.DataContextEJBQLUpdateTest) testUpdateNoQualifierMultipleItems (org.apache.cayenne.access.DataContextEJBQLUpdateTest) testUpdateNoQualifierDecimal (org.apache.cayenne.access.DataContextEJBQLUpdateTest) testUpdateNoQualifierToOne (org.apache.cayenne.access.DataContextEJBQLUpdateTest) testPreRemoveCallbacks (org.apache.cayenne.access.DataContextCallbacksTest) testObjectQueryStringBoolean (org.apache.cayenne.access.DataContextPerformQueryAPITest) testObjectQueryStringMapBoolean (org.apache.cayenne.access.DataContextPerformQueryAPITest) testProcedureQueryStringMapBoolean (org.apache.cayenne.access.DataContextPerformQueryAPITest) testNonSelectingQueryString (org.apache.cayenne.access.DataContextPerformQueryAPITest) testNonSelectingQueryStringMap (org.apache.cayenne.access.DataContextPerformQueryAPITest) testJointPrefetchDataRows(org.apache.cayenne.access.JointPrefetchTest) testJointPrefetchSQLTemplate (org.apache.cayenne.access.JointPrefetchTest) testJointPrefetchToOne(org.apache.cayenne.access.JointPrefetchTest) testJointPrefetchDataTypes (org.apache.cayenne.access.JointPrefetchTest) testJointPrefetchToMany(org.apache.cayenne.access.JointPrefetchTest) testJointPrefetchToManyNonConflictingQualifier (org.apache.cayenne.access.JointPrefetchTest) testJointPrefetchMultiStep (org.apache.cayenne.access.JointPrefetchTest) testSnapshotRetainedOnPropertyModification (org.apache.cayenne.access.ObjectStoreDiffRetainingTest) testSnapshotRetainedOnRelAndPropertyModification (org.apache.cayenne.access.ObjectStoreDiffRetainingTest)
multicolumn? Re: [jira] Commented: (CAY-400) Support for user properties of DataMap objects.
Hello. I just want to bring another example on the table. Hope I am not messing things up too much. What about multi-column information? I want to store information about db indexes that have a name, can span multiple columns and be of different types. I know this is probably out of scope for cayenne as a ORM, but very useful for us since we already store all other schema- related information in the model. If we go with a generic property map with string values, such information could be encoded into the String, but it will not be very pretty.. dbEntity.setProperty(DB-INDEX, name: myindex, type: unique, columns: col1, col2); Regards, - Tore. On Apr 14, 2009, at 10:43 , Andrus Adamchik wrote: Yes, this is a question of classification of comment property - whether we think it is generic or not... I don't have strong feelings either ways. My criteria for a generic property as being irrelevant to Cayenne runtime may not apply to comments if you use comments in DB schema generation. (BTW, is there a plan to do that?). So I am +0 on making comment an ivar. But please (re)open a separate Jira for that. Andrus On Apr 14, 2009, at 11:30 AM, Andrey Razumovsky wrote: I'm afraid I don't actually catch the point. This sounds like two separate tasks. Comments that are (re) engineered to SQL comments cannot be generic, because as far as I know, SQL specifies only one string per column, table etc. Generic properties are more flexible, but they cannot be saved in DB. And I don't like the idea of having generic property map this one specific comment key, because it makes the design blurry. So possibly we could open both tasks (?) Andrey 2009/4/14 Aristedes Maniatis a...@ish.com.au On 14/04/2009, at 6:13 PM, Andrus Adamchik wrote: I have no problem with the reduced scope. But can we still make it a generic property map initialized lazily and attached to DbAtrtribute or DbEntity, with comments being just one of the possible fields in it? I.e. the idea to group any properties not relevant to Cayenne runtime functioning in an untyped MapString, Object, instead of declaring them as ivars MapString, String might be easier unless we want to go to the trouble of typing these objects in both Cayenne modeler with another popup option and also in the XML. Mostly the user can cast them into some other data type if needed. Ari -- ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: deprecate cdeploy?
Hello. I have never used cdeploy. I mainly use jndi to configure the data sources and sometimes just plain dbcp. Regards, - Tore. On Apr 14, 2009, at 8:15 , Andrus Adamchik wrote: I never found cdeploy Ant task all that useful. Any objections to deprecating it in 3.0, with the goal to remove in 3.1? Andrus
Re: how to add a column
Thanks for the tips, but the problem was that I cloned the DataMap. Fooled by my self once again.. - Tore. On 11. april. 2009, at 11.23, Andrus Adamchik wrote: I think ClassDescriptors fails to refresh... Looks like we need to reset it inside EntityResolver.clearCache() (as well as callbackRegistry). Could you experiment with that and commit it if it works? Andrus On Apr 11, 2009, at 1:08 AM, Tore Halset wrote: Btw. This is all by code in runtime. - Tore. On Apr 11, 2009, at 0:01, Tore Halset hal...@pvv.ntnu.no wrote: Hello. I am adding a DbAttribute and a ObjAttribute to the model, but there seem to be something missing. getAttribute() on the DbEntity and ObjEntity return the correct attributes, but SelectQueries does not include the new column. I have tried to create a new DataContext and clearing the cache in the EntityResolover, but still no luck. What am I doing wrong? Regards, - Tore.
Re: how to add a column
On 11. april. 2009, at 21.12, Tore Halset wrote: Thanks for the tips, but the problem was that I cloned the DataMap. Fooled by my self once again.. Some more details. When I figured about the cloning, I did not even have to clear EntityResolver cache to make queries working. - Tore.
Re: [jira] Commented: (CAY-1037) DbGenerator destroys auto pk support
On 9. mars. 2009, at 11.34, Tore Halset wrote: Hello. On Mar 9, 2009, at 10:27 , Andrus Adamchik wrote: On Mar 6, 2009, at 11:27 PM, Øyvind Harboe (JIRA) wrote: Øyvind Harboe commented on CAY-1037: I no longer use DbGenerator. Should DbGenerator be deprecated? The new MergerContext stuff is a million times better for my purposes: to add new tables/columns to the database if the model changed and the database didn't. I am very much in favor of doing that. In practical terms it means switching Modeler / Ant / Maven to the MergerContext, and add support for some missing databases. Wonder if we still need to preserve generate all mode. I think the merger stuff (nice name) has some limitations related to the order the different tokens are performed preventing us from deprecating DbGenerator. Within a single entity, different tokens are ordered correctly, but there may be some problems with several dependent entities and relationships between them. Before this is fixed/improved, I still think we need DbGenerator. Sorry. I think I found an easy solution to this now by adding all the AddRelationshipToDb tokens at the end. It seem to work for my model.. Regards, - Tore.
how to add a column
Hello. I am adding a DbAttribute and a ObjAttribute to the model, but there seem to be something missing. getAttribute() on the DbEntity and ObjEntity return the correct attributes, but SelectQueries does not include the new column. I have tried to create a new DataContext and clearing the cache in the EntityResolover, but still no luck. What am I doing wrong? Regards, - Tore.
Re: how to add a column
Btw. This is all by code in runtime. - Tore. On Apr 11, 2009, at 0:01, Tore Halset hal...@pvv.ntnu.no wrote: Hello. I am adding a DbAttribute and a ObjAttribute to the model, but there seem to be something missing. getAttribute() on the DbEntity and ObjEntity return the correct attributes, but SelectQueries does not include the new column. I have tried to create a new DataContext and clearing the cache in the EntityResolover, but still no luck. What am I doing wrong? Regards, - Tore.
Re: [jira] Commented: (CAY-1037) DbGenerator destroys auto pk support
Hello. On Mar 9, 2009, at 10:27 , Andrus Adamchik wrote: On Mar 6, 2009, at 11:27 PM, Øyvind Harboe (JIRA) wrote: Øyvind Harboe commented on CAY-1037: I no longer use DbGenerator. Should DbGenerator be deprecated? The new MergerContext stuff is a million times better for my purposes: to add new tables/columns to the database if the model changed and the database didn't. I am very much in favor of doing that. In practical terms it means switching Modeler / Ant / Maven to the MergerContext, and add support for some missing databases. Wonder if we still need to preserve generate all mode. I think the merger stuff (nice name) has some limitations related to the order the different tokens are performed preventing us from deprecating DbGenerator. Within a single entity, different tokens are ordered correctly, but there may be some problems with several dependent entities and relationships between them. Before this is fixed/improved, I still think we need DbGenerator. Sorry. Regards, - Tore.
Re: [VOTE] 3.0M5 Release
Hello. -1 as it breaks my production system as described in an email from me 5/12. I am currently tesing this with Andrus latest fix. - Tore. On Dec 2, 2008, at 14:10, Kevin Menard wrote: Hi all, I'm raising the vote release Cayenne 3.0 M5. I've prepared and signed the 3.0M5 binaries and they are available here: http://people.apache.org/~kmenard/release/3.0M5/ Here is my +1 for the release. -- Kevin
Re: testing M5 - StackOverflowError during context.deleteObject()
Hello. I retried this now and everything seems to be working fine. No more StackOverflowError. I probably did something wrong in my build yesterday. Now, everything seems fine. Thanks for looking into this Andrus. Regards, - Tore. On Dec 7, 2008, at 21:16 , Tore Halset wrote: On Dec 7, 2008, at 17:26, Andrus Adamchik wrote: Tore, I committed a fix (essentially undoing ~60% of CAY-1138) to both trunk and M5 tag. Could you please try it out before we create the new artifacts? Sorry, but the latest trunk did not fix the problem. I will have to work more on this tomorrow. - Tore.
Re: testing M5 - StackOverflowError during context.deleteObject()
On Dec 5, 2008, at 15:03 , Andrus Adamchik wrote: Hmm... actually looking closer at the stack, this has nothing to do with initialization of descriptors. This is some circular object faulting. Still a DataMap would help. Okay and thanks for looking into it. I have sent the mapping to you outside of the list. - Tore.
Re: Preparing 3.0M5
On Nov 24, 2008, at 1:48 , Kevin Menard wrote: PostgreSQL (8.3.1): 1 failure 83 errors Did you do a createlang plpgsql databasename? I got fooled by that one before. And so did you back in january :) - Tore.
deprecated - Re: Removing @author tags
On 11. nov.. 2008, at 17.32, Andrey Razumovsky wrote: Next step in cleaning Cayenne code can be removal of using of deprecated methods, unused imports etc. What is the plan here? Do you plan to remove things that was not deprecated in the 1.2/2.2 as well? Is that ok since we are shifting to a new major number or do we plan to make the transition as easy as possible for users? I still have lots and lots of .getDataContext() and .createAndRegisterNewObject() in my projects. I guess I should fix them as soon as possible :) Regards, - Tore.
Re: Removing @author tags
On Nov 10, 2008, at 8:57 , Andrus Adamchik wrote: I'd like to suggest stripping @author tags from all Java classes. +1 Regards, - Tore.
[jira] Created: (CAY-1124) DataRowStore blocked
DataRowStore blocked Key: CAY-1124 URL: https://issues.apache.org/cayenne/browse/CAY-1124 Project: Cayenne Issue Type: Bug Components: Cayenne Core Library Affects Versions: 3.0 Environment: 3.0M3 Reporter: Tore Halset Assignee: Tore Halset Fix For: 3.0 I have gotten this one a couple of times on our production system running 3.0M3. As far as I see, this code has not been improved since 3.0M3, so I register this as a major bug. TP-Processor5 daemon prio=10 tid=0x2aab798c0400 nid=0xc2e waiting for monitor entry [0x43e64000..0x00 0043e66bb0] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.cayenne.access.DataRowStore.getCachedSnapshot(DataRowStore.java:351) - waiting to lock 0x2aaab91a5c40 (a org.apache.cayenne.access.DataRowStore) at org.apache.cayenne.access.DataDomainQueryAction.interceptOIDQuery(DataDomainQueryAction.java:174) at org.apache.cayenne.access.DataDomainQueryAction.execute(DataDomainQueryAction.java:114) at org.apache.cayenne.access.DataDomain.onQuery(DataDomain.java:740) at org.apache.cayenne.util.ObjectContextQueryAction.runQuery(ObjectContextQueryAction.java:296) at org.apache.cayenne.util.ObjectContextQueryAction.execute(ObjectContextQueryAction.java:84) at org.apache.cayenne.access.DataContext.onQuery(DataContext.java:1331) at org.apache.cayenne.access.DataContext.performQuery(DataContext.java:1320) at org.apache.cayenne.DataObjectUtils.objectForQuery(DataObjectUtils.java:275) at org.apache.cayenne.DataObjectUtils.objectForPK(DataObjectUtils.java:261) at org.apache.cayenne.DataObjectUtils.objectForPK(DataObjectUtils.java:172) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAY-1124) DataRowStore blocked
[ https://issues.apache.org/cayenne/browse/CAY-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset updated CAY-1124: - Description: I have gotten this one a couple of times on our production system running 3.0M3. As far as I see, this code has not been improved since 3.0M3, so I register this as a major bug. TP-Processor5 daemon prio=10 tid=0x2aab798c0400 nid=0xc2e waiting for monitor entry [0x43e64000..0x00 0043e66bb0] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.cayenne.access.DataRowStore.getCachedSnapshot(DataRowStore.java:351) - waiting to lock 0x2aaab91a5c40 (a org.apache.cayenne.access.DataRowStore) at org.apache.cayenne.access.DataDomainQueryAction.interceptOIDQuery(DataDomainQueryAction.java:174) at org.apache.cayenne.access.DataDomainQueryAction.execute(DataDomainQueryAction.java:114) at org.apache.cayenne.access.DataDomain.onQuery(DataDomain.java:740) at org.apache.cayenne.util.ObjectContextQueryAction.runQuery(ObjectContextQueryAction.java:296) at org.apache.cayenne.util.ObjectContextQueryAction.execute(ObjectContextQueryAction.java:84) at org.apache.cayenne.access.DataContext.onQuery(DataContext.java:1331) at org.apache.cayenne.access.DataContext.performQuery(DataContext.java:1320) at org.apache.cayenne.DataObjectUtils.objectForQuery(DataObjectUtils.java:275) at org.apache.cayenne.DataObjectUtils.objectForPK(DataObjectUtils.java:261) at org.apache.cayenne.DataObjectUtils.objectForPK(DataObjectUtils.java:172) DefaultQuartzScheduler_Worker-10 prio=10 tid=0x2aab7afedc00 nid=0xc20 waiting for monitor entry [0x43a62000..0x43a62db0] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.cayenne.access.DataRowStore.getCachedSnapshot(DataRowStore.java:351) - waiting to lock 0x2aaab91a5c40 (a org.apache.cayenne.access.DataRowStore) at org.apache.cayenne.access.DataDomainQueryAction.interceptOIDQuery(DataDomainQueryAction.java:174) at org.apache.cayenne.access.DataDomainQueryAction.execute(DataDomainQueryAction.java:114) at org.apache.cayenne.access.DataDomain.onQuery(DataDomain.java:740) at org.apache.cayenne.util.ObjectContextQueryAction.runQuery(ObjectContextQueryAction.java:296) at org.apache.cayenne.util.ObjectContextQueryAction.execute(ObjectContextQueryAction.java:84) at org.apache.cayenne.access.DataContext.onQuery(DataContext.java:1331) at org.apache.cayenne.access.DataContext.performQuery(DataContext.java:1320) at org.apache.cayenne.DataObjectUtils.objectForQuery(DataObjectUtils.java:275) at org.apache.cayenne.DataObjectUtils.objectForPK(DataObjectUtils.java:261) at org.apache.cayenne.DataObjectUtils.objectForPK(DataObjectUtils.java:172) DefaultQuartzScheduler_Worker-3 prio=10 tid=0x2aab7af02c00 nid=0xc19 waiting for monitor entry [0x4335b000..0x4335be30] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.cayenne.access.DataRowStore.snapshotsUpdatedForObjects(DataRowStore.java:234) - waiting to lock 0x2aaab91a5c40 (a org.apache.cayenne.access.DataRowStore) at org.apache.cayenne.access.ObjectResolver.objectsFromDataRows(ObjectResolver.java:125) at org.apache.cayenne.access.ObjectResolver.synchronizedObjectsFromDataRows(ObjectResolver.java:101) - locked 0x2aaabb39bb70 (a org.apache.cayenne.access.ObjectStore) at org.apache.cayenne.access.DataDomainQueryAction.interceptObjectConversion(DataDomainQueryAction.java:460) at org.apache.cayenne.access.DataDomainQueryAction.execute(DataDomainQueryAction.java:129) at org.apache.cayenne.access.DataDomain.onQuery(DataDomain.java:740) at org.apache.cayenne.util.ObjectContextQueryAction.runQuery(ObjectContextQueryAction.java:296) at org.apache.cayenne.util.ObjectContextQueryAction.execute(ObjectContextQueryAction.java:84) at org.apache.cayenne.access.DataContext.onQuery(DataContext.java:1331) at org.apache.cayenne.access.DataContext.performQuery(DataContext.java:1320) was: I have gotten this one a couple of times on our production system running 3.0M3. As far as I see, this code has not been improved since 3.0M3, so I register this as a major bug. TP-Processor5 daemon prio=10 tid=0x2aab798c0400 nid=0xc2e waiting for monitor entry [0x43e64000..0x00 0043e66bb0] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.cayenne.access.DataRowStore.getCachedSnapshot(DataRowStore.java:351) - waiting to lock 0x2aaab91a5c40 (a org.apache.cayenne.access.DataRowStore) at org.apache.cayenne.access.DataDomainQueryAction.interceptOIDQuery(DataDomainQueryAction.java:174
[jira] Commented: (CAY-1124) DataRowStore blocked
[ https://issues.apache.org/cayenne/browse/CAY-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13167#action_13167 ] Tore Halset commented on CAY-1124: -- In the same thread dump, there were some other RUNNABLE that also looked strange. I do not know if those are relevant. TP-Processor12 daemon prio=10 tid=0x2aab77946400 nid=0x166d runnable [0x44d74000..0x44d75db0] java.lang.Thread.State: RUNNABLE at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethod(Class.java:1935) at org.apache.cayenne.util.Invocation.lookupMethodInHierarchy(Invocation.java:134) at org.apache.cayenne.util.Invocation.init(Invocation.java:111) at org.apache.cayenne.util.Invocation.init(Invocation.java:65) at org.apache.cayenne.event.EventManager$NonBlockingInvocation.init(EventManager.java:436) at org.apache.cayenne.event.EventManager.addListener(EventManager.java:216) at org.apache.cayenne.event.EventManager.addNonBlockingListener(EventManager.java:192) at org.apache.cayenne.access.ObjectStore.setDataRowCache(ObjectStore.java:262) at org.apache.cayenne.access.ObjectStore.init(ObjectStore.java:129) at org.apache.cayenne.access.ObjectStore.init(ObjectStore.java:118) at org.apache.cayenne.access.DataDomain.createDataContext(DataDomain.java:601) TP-Processor11 daemon prio=10 tid=0x2aab77945800 nid=0x166c runnable [0x44c73000..0x44c74b30] java.lang.Thread.State: RUNNABLE at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethod(Class.java:1935) at org.apache.cayenne.util.Invocation.lookupMethodInHierarchy(Invocation.java:134) at org.apache.cayenne.util.Invocation.init(Invocation.java:111) at org.apache.cayenne.util.Invocation.init(Invocation.java:65) at org.apache.cayenne.event.EventManager$NonBlockingInvocation.init(EventManager.java:436) at org.apache.cayenne.event.EventManager.addListener(EventManager.java:216) at org.apache.cayenne.event.EventManager.addNonBlockingListener(EventManager.java:192) at org.apache.cayenne.access.ObjectStore.setDataRowCache(ObjectStore.java:262) at org.apache.cayenne.access.ObjectStore.init(ObjectStore.java:129) at org.apache.cayenne.access.ObjectStore.init(ObjectStore.java:118) at org.apache.cayenne.access.DataDomain.createDataContext(DataDomain.java:601) TP-Processor7 daemon prio=10 tid=0x2aab798c1800 nid=0xc30 runnable [0x44067000..0x44068ab0] java.lang.Thread.State: RUNNABLE at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethod(Class.java:1935) at org.apache.cayenne.util.Invocation.lookupMethodInHierarchy(Invocation.java:134) at org.apache.cayenne.util.Invocation.init(Invocation.java:111) at org.apache.cayenne.util.Invocation.init(Invocation.java:65) at org.apache.cayenne.event.EventManager$NonBlockingInvocation.init(EventManager.java:436) at org.apache.cayenne.event.EventManager.addListener(EventManager.java:216) at org.apache.cayenne.event.EventManager.addNonBlockingListener(EventManager.java:192) at org.apache.cayenne.access.ObjectStore.setDataRowCache(ObjectStore.java:262) at org.apache.cayenne.access.ObjectStore.init(ObjectStore.java:129) at org.apache.cayenne.access.ObjectStore.init(ObjectStore.java:118) at org.apache.cayenne.access.DataDomain.createDataContext(DataDomain.java:601) DefaultQuartzScheduler_Worker-1 prio=10 tid=0x2aab7b157c00 nid=0xc17 runnable [0x43159000..0x4315 9b30] java.lang.Thread.State: RUNNABLE at org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.hasNext(AbstractReferenceM ap.java:736) at org.apache.cayenne.access.ObjectStore.postprocessAfterCommit(ObjectStore.java:442) at org.apache.cayenne.access.DataDomainFlushAction.postprocess(DataDomainFlushAction.java:258) at org.apache.cayenne.access.DataDomainFlushAction.flush(DataDomainFlushAction.java:150) - locked 0x2aaab91a5c40 (a org.apache.cayenne.access.DataRowStore) at org.apache.cayenne.access.DataDomain.onSyncFlush(DataDomain.java:821) at org.apache.cayenne.access.DataDomain$2.transform(DataDomain.java:788) at org.apache.cayenne.access.DataDomain.runInTransaction(DataDomain.java:847) at org.apache.cayenne.access.DataDomain.onSync(DataDomain.java:785) at org.apache.cayenne.access.DataContext.flushToParent
[jira] Closed: (CAY-1117) Class Cast Exception in SQLServerMergerFactory from AutoAdapter to SQLServerAdapter
[
https://issues.apache.org/cayenne/browse/CAY-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tore Halset closed CAY-1117.
Assignee: Tore Halset (was: Andrus Adamchik)
Class Cast Exception in SQLServerMergerFactory from AutoAdapter to
SQLServerAdapter
---
Key: CAY-1117
URL: https://issues.apache.org/cayenne/browse/CAY-1117
Project: Cayenne
Issue Type: Bug
Components: Cayenne Core Library
Affects Versions: 2.0 [STABLE]
Environment: Windows XP, 1.6.0_07 by Sun Microsystems Inc., Microsoft
SQL Server
Reporter: Laurentiu Cocanu
Assignee: Tore Halset
Fix For: 3.0
In
cayenne/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/dba/sqlserver/SQLServerMergerFactory.java,
the following method
@Override
public MergerToken createSetNotNullToDb(DbEntity entity, final
DbAttribute column) {
return new SetNotNullToDb(entity, column) {
@Override
public ListString createSql(DbAdapter adapter) {
StringBuffer sqlBuffer = new StringBuffer();
sqlBuffer.append(ALTER TABLE );
sqlBuffer.append(getEntity().getFullyQualifiedName());
sqlBuffer.append( ALTER COLUMN );
SQLServerAdapter sqladapter = (SQLServerAdapter) adapter;
sqladapter.createTableAppendColumn(sqlBuffer, column);
return Collections.singletonList(sqlBuffer.toString());
}
};
}
the cast SQLServerAdapter sqladapter = (SQLServerAdapter) adapter; will raise
a Class Cast Exception.
A possible fix could be eliminating this cast as createTableAppendColumn
method is defined in DbAdapter interface, so the cast is useless.
See
http://www.nabble.com/Upcast-problems-w-SQLServerMergerFactory-and-AutoAdapter-td19664724.html
(the patch is known but not implemented yet)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CAY-1108) [PATCH] MySQL/DbMerger compatibility
[ https://issues.apache.org/cayenne/browse/CAY-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset closed CAY-1108. Resolution: Fixed Fix Version/s: 3.0 I think this one is fixed and it is included in the release notes. The code reuse patch is not included yet as I do not think it is related to this issue. If it is important to make merging work on MySQL, then please reopen or create a new issue. [PATCH] MySQL/DbMerger compatibility Key: CAY-1108 URL: https://issues.apache.org/cayenne/browse/CAY-1108 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Affects Versions: 3.0 Reporter: Scott Anderson Assignee: Tore Halset Fix For: 3.0 Attachments: increase_reuse.patch, increase_reuse2.patch, SetNotNullToDb-MySQL.patch This patch will generate proper SQL for changing a MySQL field to NOT NULL -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAY-1108) [PATCH] MySQL/DbMerger compatibility
[ https://issues.apache.org/cayenne/browse/CAY-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13105#action_13105 ] Tore Halset commented on CAY-1108: -- I have added the SetNotNullToDb-MySQL.patch. Thanks Scott! I have not added the increase_reuse.patch as that would make SetColumnTypeToDb and AddColumnToDb include the not null clause. We need not null to be a separate token to be able to add a default value after the column is added, but before setting not null. Please report back if this is ok Scott! [PATCH] MySQL/DbMerger compatibility Key: CAY-1108 URL: https://issues.apache.org/cayenne/browse/CAY-1108 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Affects Versions: 3.0 Reporter: Scott Anderson Assignee: Tore Halset Attachments: increase_reuse.patch, SetNotNullToDb-MySQL.patch This patch will generate proper SQL for changing a MySQL field to NOT NULL -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r689323 - /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/test/java/org/apache/cayenne/merge/DropColumnToModelTest.java
Thanks and Sorry! - Tore. On Aug 27, 2008, at 03:21, [EMAIL PROTECTED] wrote: Author: kmenard Date: Tue Aug 26 18:21:55 2008 New Revision: 689323 URL: http://svn.apache.org/viewvc?rev=689323view=rev Log: Updated a test based on Tore's fix of a typo in the main code. Modified: cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/test/ java/org/apache/cayenne/merge/DropColumnToModelTest.java Modified: cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/ src/test/java/org/apache/cayenne/merge/DropColumnToModelTest.java URL: http://svn.apache.org/viewvc/cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/test/java/org/apache/cayenne/merge/DropColumnToModelTest.java?rev=689323r1=689322r2=689323view=diff = = = = = = = = == --- cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/test/ java/org/apache/cayenne/merge/DropColumnToModelTest.java (original) +++ cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/test/ java/org/apache/cayenne/merge/DropColumnToModelTest.java Tue Aug 26 18:21:55 2008 @@ -63,7 +63,7 @@ map.addObjEntity(objEntity); // force drop name column in db -MergerToken token = mergerFactory().createDropColumToDb(dbEntity, column2); +MergerToken token = mergerFactory().createDropColumnToDb(dbEntity, column2); execute(token); ListMergerToken tokens = createMergeTokens(); @@ -128,7 +128,7 @@ assertTokensAndExecute(node, map, 0, 0); // force drop fk column in db -execute(mergerFactory().createDropColumToDb(dbEntity2, e2col2)); +execute(mergerFactory().createDropColumnToDb(dbEntity2, e2col2)); // create db relationships, but do not sync them to db DbRelationship rel1To2 = new DbRelationship(rel1To2);
[jira] Created: (CAY-1100) merge: make getColumnOriginal() and getColumnNew() public
merge: make getColumnOriginal() and getColumnNew() public - Key: CAY-1100 URL: https://issues.apache.org/cayenne/browse/CAY-1100 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Affects Versions: 3.0 Reporter: Tore Halset Assignee: Tore Halset Priority: Minor Øyvind: How about exposing the above two attributes in getColumnOriginal() and getColumnNew()? http://mail-archives.apache.org/mod_mbox/cayenne-user/200808.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CAY-1100) merge: make getColumnOriginal() and getColumnNew() public
[ https://issues.apache.org/cayenne/browse/CAY-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset closed CAY-1100. added to RELEASE-NOTES.txt merge: make getColumnOriginal() and getColumnNew() public - Key: CAY-1100 URL: https://issues.apache.org/cayenne/browse/CAY-1100 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Affects Versions: 3.0 Reporter: Tore Halset Assignee: Tore Halset Priority: Minor Fix For: 3.0 Øyvind: How about exposing the above two attributes in getColumnOriginal() and getColumnNew()? http://mail-archives.apache.org/mod_mbox/cayenne-user/200808.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 3.0 M5?
Hello. +1 The modeler-work is a milestone. - Tore. On Aug 15, 2008, at 21:59, Kevin Menard wrote: It's coming up on 3 months since the release of M4. While an M5 now wouldn't have as many changes as M4 did, it's probably still worthwhile getting it out there. It'd be nice to get all of Andrey's hard work out in the hands of our users. I know there are still some things that need to be cleaned up. But, if people are open to it, I'd like to start planning the timeline for the M5 release. -- Kevin
frontbase testing
Hello. I am testing on FrontBase as well and got into some problems with add/ drop not null constraints in the merge stuff. For dropping a not null constraint, you need to create a view for a system table, join ~4 views from some information tables, and then issue some alter table statements. So for this single merge-token, I need at least two steps to the database. The result of the first step, the constraint name, will then be used to create the second statement. I have not included support for several roundtrips in a single merge-token, so this is kind of hard. A FrontBase guy sent me a stored procedure for this that does all of that in a single step, but I do not know the license issues involved in using that code. Should I create a jira and ask him to post the procedure there? Will that be enough? Regards, - Tore.
[jira] Commented: (CAY-1063) Derby adapter is not able to remove NOT NULL relationship
[ https://issues.apache.org/cayenne/browse/CAY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003#action_13003 ] Tore Halset commented on CAY-1063: -- fixed for sqlserver and openbase Derby adapter is not able to remove NOT NULL relationship - Key: CAY-1063 URL: https://issues.apache.org/cayenne/browse/CAY-1063 Project: Cayenne Issue Type: Bug Components: Cayenne Core Library Affects Versions: 3.0 Environment: Does Derby even support this operation? Reporter: Øyvind Harboe Assignee: Tore Halset Priority: Minor Fix For: 3.0 31000 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - Detected and installed adapter: org.apache.cayenne.dba.derby.DerbyAdapter 45641 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - ALTER TABLE log_email ALTER COLUMN sender DROP NOT NULL 45704 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - *** error. java.sql.SQLException: Syntax error: Encountered DROP at line 1, column 43. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.cayenne.merge.ExecutingMergerContext.executeSql(ExecutingMergerContext.java:60) at org.apache.cayenne.merge.AbstractToDbToken.execute(AbstractToDbToken.java:41) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
sqlserver testing
Hello. For some reason, DataContextEJBQLQueryTest hang when testing on sql server. I have tried with jtds and the jdbc driver for SQL Server 2005. The database I am testing on is SQL Server 2000. I had to delete that test to be able to continue. I fixed add/drop null for merging, so all of the merge stuff should work for sqlserver now. At the bottom, you will see the remaining fails. The last two are for case sensitive searching. Perhaps the database I am testing on is configured wrong? We had some problems with this when we converted from MS SQL Server to PostgreSQL as searching is case sensitive in PostgreSQL. - Tore. framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org.apache.cayenne.access.DataContextEJBQLArrayResultTest.txt:Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.179 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org.apache.cayenne.access.DataContextOuterJoinsTest.txt:Tests run: 4, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.206 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org .apache .cayenne .access .DataContextOuterJoinsTest .txt:testSelectWithOuterJoin (org.apache.cayenne.access.DataContextOuterJoinsTest) Time elapsed: 0.055 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org .apache .cayenne .access .DataContextOuterJoinsTest .txt:testSelectWithOuterJoinFromString (org.apache.cayenne.access.DataContextOuterJoinsTest) Time elapsed: 0.042 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org.apache.cayenne.query.SelectQueryTest.txt:Tests run: 27, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.145 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org .apache .cayenne .query .SelectQueryTest .txt:testSelectLikeCaseSensitive (org.apache.cayenne.query.SelectQueryTest) Time elapsed: 0.042 sec FAILURE!
Re: openbase testing
On 5. juli. 2008, at 21.27, Andrus Adamchik wrote: On Jul 5, 2008, at 10:21 PM, Tore Halset wrote: Yeah, some (most?) of these are known issues I think: https://issues.apache.org/cayenne/browse/CAY-820 I have posted a couple of issues to OpenBase developer list. Should I post this as well or have you done it already? IIRC I did notify OpenBase about it at the time (1 year ago). But I never had a chance to test against newer versions to see if there was any progress. Okay. I tested them now, and the problems still exist. I'll send a mail to the developer list. - Tore.
openbase testing
Hello. I fixed merging and added the join syntax. There is still some tests that fails. (I do not use openbase for anything, just wanted to try something different after a lot of oracle-install-frustration...) - Tore. framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org.apache.cayenne.access.DataContextEJBQLArrayResultTest.txt:Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.085 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org.apache.cayenne.access.DataContextEJBQLConditionsTest.txt:Tests run: 16, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 0.332 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org .apache .cayenne .access .DataContextEJBQLConditionsTest .txt:testCollectionEmpty (org.apache.cayenne.access.DataContextEJBQLConditionsTest) Time elapsed: 0.02 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org.apache.cayenne.access.DataContextEJBQLGroupByHavingTest.txt:Tests run: 6, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.139 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org.apache.cayenne.access.DataContextEJBQLSubqueryTest.txt:Tests run: 6, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.269 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org.apache.cayenne.access.DataContextOuterJoinsTest.txt:Tests run: 4, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 0.102 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org .apache .cayenne .access .DataContextOuterJoinsTest .txt:testSelectWithOuterJoinFlattened (org.apache.cayenne.access.DataContextOuterJoinsTest) Time elapsed: 0.037 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org .apache .cayenne .access .DataContextOuterJoinsTest .txt:testSelectWithOuterJoin (org.apache.cayenne.access.DataContextOuterJoinsTest) Time elapsed: 0.024 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org .apache .cayenne .access .DataContextOuterJoinsTest .txt:testSelectWithOuterJoinFromString (org.apache.cayenne.access.DataContextOuterJoinsTest) Time elapsed: 0.019 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org.apache.cayenne.access.DataContextSQLTemplateTest.txt:Tests run: 19, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.529 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org.apache.cayenne.access.SimpleIdIncrementalFaultListTest.txt:Tests run: 15, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.734 sec FAILURE! framework/cayenne-jdk1.5-unpublished/target/surefire-reports/ org .apache .cayenne .access .SimpleIdIncrementalFaultListTest .txt:testNewObject (org.apache.cayenne.access.SimpleIdIncrementalFaultListTest) Time elapsed: 0.067 sec FAILURE!
[jira] Commented: (CAY-1084) openbase does not like our join syntax :(
[ https://issues.apache.org/cayenne/browse/CAY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998#action_12998 ] Tore Halset commented on CAY-1084: -- I have joined the list, but is not able to post as I do not know what the mail adr is. Really strange. Will do. Added support for the current OpenBase join syntax. It still fails some tests as the outer joins behaves a little different. It looks like checking for null does not work if you want rows that does not have a related row on the right side of the join. or so. Will keep this one open a little while to see what happens.. openbase does not like our join syntax :( - Key: CAY-1084 URL: https://issues.apache.org/cayenne/browse/CAY-1084 Project: Cayenne Issue Type: Bug Components: Cayenne Core Library Affects Versions: 3.0 Environment: OpenBase 10.0.11 Reporter: Tore Halset Assignee: Tore Halset Hello. Just tried the junit tests on OpenBase and it did not work very well. A lot of the problems is from the join syntax that OpenBase seem to have problems with. INFO: SELECT t0.COLLECTION_TO_MANY_ID, t0.ID FROM COLLECTION_TO_MANY_TARGET t0 JOIN COLLECTION_TO_MANY t1 ON (t0.COLLECTION_TO_MANY_ID = t1.ID) WHERE t1.ID = ? [bind: 1-ID:1] INFO: *** error. java.sql.SQLException: SQL ERROR - [position 72, near 'JOIN' in '_TARGET t0 JOIN COLLECTIO'] comma or JOIN syntax expected but not found in from clause. SQL: SELECT t0.COLLECTION_TO_MANY_ID, t0.ID FROM COLLECTION_TO_MANY_TARGET t0 JOIN COLLECTION_TO_MANY t1 ON (t0.COLLECTION_TO_MANY_ID = t1.ID) WHERE t1.ID = 1 at com.openbase.net.c.a(Unknown Source) at com.openbase.jdbc.c.a(Unknown Source) at com.openbase.jdbc.c.a(Unknown Source) at com.openbase.jdbc.i.executeQuery(Unknown Source) at org.apache.cayenne.access.jdbc.SelectAction.performAction(SelectAction.java:73) This looks like the documentation for select statements including join. The JOIN keyword is not shown at all. http://www.openbase.com/help/KnowledgeBase/400_OpenBaseSQL/401_SelectStatements.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CAY-1084) openbase does not like our join syntax :(
openbase does not like our join syntax :( - Key: CAY-1084 URL: https://issues.apache.org/cayenne/browse/CAY-1084 Project: Cayenne Issue Type: Bug Components: Cayenne Core Library Affects Versions: 3.0 Environment: OpenBase 10.0.11 Reporter: Tore Halset Hello. Just tried the junit tests on OpenBase and it did not work very well. A lot of the problems is from the join syntax that OpenBase seem to have problems with. INFO: SELECT t0.COLLECTION_TO_MANY_ID, t0.ID FROM COLLECTION_TO_MANY_TARGET t0 JOIN COLLECTION_TO_MANY t1 ON (t0.COLLECTION_TO_MANY_ID = t1.ID) WHERE t1.ID = ? [bind: 1-ID:1] INFO: *** error. java.sql.SQLException: SQL ERROR - [position 72, near 'JOIN' in '_TARGET t0 JOIN COLLECTIO'] comma or JOIN syntax expected but not found in from clause. SQL: SELECT t0.COLLECTION_TO_MANY_ID, t0.ID FROM COLLECTION_TO_MANY_TARGET t0 JOIN COLLECTION_TO_MANY t1 ON (t0.COLLECTION_TO_MANY_ID = t1.ID) WHERE t1.ID = 1 at com.openbase.net.c.a(Unknown Source) at com.openbase.jdbc.c.a(Unknown Source) at com.openbase.jdbc.c.a(Unknown Source) at com.openbase.jdbc.i.executeQuery(Unknown Source) at org.apache.cayenne.access.jdbc.SelectAction.performAction(SelectAction.java:73) This looks like the documentation for select statements including join. The JOIN keyword is not shown at all. http://www.openbase.com/help/KnowledgeBase/400_OpenBaseSQL/401_SelectStatements.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAY-1084) openbase does not like our join syntax :(
[ https://issues.apache.org/cayenne/browse/CAY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991#action_12991 ] Tore Halset commented on CAY-1084: -- ..Probably by subclassing JoinStack and also make it possible for the JoinStack to output stuff after WHERE. openbase does not like our join syntax :( - Key: CAY-1084 URL: https://issues.apache.org/cayenne/browse/CAY-1084 Project: Cayenne Issue Type: Bug Components: Cayenne Core Library Affects Versions: 3.0 Environment: OpenBase 10.0.11 Reporter: Tore Halset Hello. Just tried the junit tests on OpenBase and it did not work very well. A lot of the problems is from the join syntax that OpenBase seem to have problems with. INFO: SELECT t0.COLLECTION_TO_MANY_ID, t0.ID FROM COLLECTION_TO_MANY_TARGET t0 JOIN COLLECTION_TO_MANY t1 ON (t0.COLLECTION_TO_MANY_ID = t1.ID) WHERE t1.ID = ? [bind: 1-ID:1] INFO: *** error. java.sql.SQLException: SQL ERROR - [position 72, near 'JOIN' in '_TARGET t0 JOIN COLLECTIO'] comma or JOIN syntax expected but not found in from clause. SQL: SELECT t0.COLLECTION_TO_MANY_ID, t0.ID FROM COLLECTION_TO_MANY_TARGET t0 JOIN COLLECTION_TO_MANY t1 ON (t0.COLLECTION_TO_MANY_ID = t1.ID) WHERE t1.ID = 1 at com.openbase.net.c.a(Unknown Source) at com.openbase.jdbc.c.a(Unknown Source) at com.openbase.jdbc.c.a(Unknown Source) at com.openbase.jdbc.i.executeQuery(Unknown Source) at org.apache.cayenne.access.jdbc.SelectAction.performAction(SelectAction.java:73) This looks like the documentation for select statements including join. The JOIN keyword is not shown at all. http://www.openbase.com/help/KnowledgeBase/400_OpenBaseSQL/401_SelectStatements.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CAY-1084) openbase does not like our join syntax :(
[ https://issues.apache.org/cayenne/browse/CAY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991#action_12991 ] halset edited comment on CAY-1084 at 7/1/08 1:39 PM: -- ..Probably by subclassing JoinStack and also make it possible for the JoinStack to output stuff after WHERE in the SelectTranslator. was (Author: halset): ..Probably by subclassing JoinStack and also make it possible for the JoinStack to output stuff after WHERE. openbase does not like our join syntax :( - Key: CAY-1084 URL: https://issues.apache.org/cayenne/browse/CAY-1084 Project: Cayenne Issue Type: Bug Components: Cayenne Core Library Affects Versions: 3.0 Environment: OpenBase 10.0.11 Reporter: Tore Halset Hello. Just tried the junit tests on OpenBase and it did not work very well. A lot of the problems is from the join syntax that OpenBase seem to have problems with. INFO: SELECT t0.COLLECTION_TO_MANY_ID, t0.ID FROM COLLECTION_TO_MANY_TARGET t0 JOIN COLLECTION_TO_MANY t1 ON (t0.COLLECTION_TO_MANY_ID = t1.ID) WHERE t1.ID = ? [bind: 1-ID:1] INFO: *** error. java.sql.SQLException: SQL ERROR - [position 72, near 'JOIN' in '_TARGET t0 JOIN COLLECTIO'] comma or JOIN syntax expected but not found in from clause. SQL: SELECT t0.COLLECTION_TO_MANY_ID, t0.ID FROM COLLECTION_TO_MANY_TARGET t0 JOIN COLLECTION_TO_MANY t1 ON (t0.COLLECTION_TO_MANY_ID = t1.ID) WHERE t1.ID = 1 at com.openbase.net.c.a(Unknown Source) at com.openbase.jdbc.c.a(Unknown Source) at com.openbase.jdbc.c.a(Unknown Source) at com.openbase.jdbc.i.executeQuery(Unknown Source) at org.apache.cayenne.access.jdbc.SelectAction.performAction(SelectAction.java:73) This looks like the documentation for select statements including join. The JOIN keyword is not shown at all. http://www.openbase.com/help/KnowledgeBase/400_OpenBaseSQL/401_SelectStatements.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: oracle anyone?
On 22. juni. 2008, at 02.05, Aristedes Maniatis wrote: If you mean, run Cayenne unit and integration tests, Yes. then my goal is to install a range of databases in our Cayenne zone and have Hudson run them automatically. I've spent quite a few hours on this already, but am finding it very difficult to install things in the restricted sandbox we have inside the zone. If you have more Solaris experience and can navigate around the limits imposed by the zone, I'd love help to get them installed. Unfortunately from tomorrow I am travelling for a month, so I'll not be very available for a little while. So what have you installed? It is some years since I used Solaris for anything serious. Oracle has a free license for Windows/Linux (but not Solaris I think) with the limitation of only being able to create a single database. We do our testing in our office with this version running on Windows. You have to register on the Oracle web site and they send you endless marketing information. I have downloaded this for linux and have a box to install it on. Should probably try to install it.. Just afraid of all the uninteresting oracle-trouble I will get into... - Tore.
Re: Wrapping up Cayenne 3.0
Hello. I am +1 to start wrapping up 3.0. I want to create some modeler documentation for the merge-stuff. I volunteered to join in on JPA, but lost motivation. At first it sounded like fun, but then I discovered that it was a lot of work ... and that I would probably not use it myself. I have a lot of respect for the work done and still think it is one of the most important things for cayenne after joining Apache. Regards, - Tore. On 18. juni. 2008, at 15.06, Andrus Adamchik wrote: Wanted to float the idea of wrapping up 3.0 release. Contrary to what I said in the past (3.0 final == certified JPA release), there are a few considerations that made me change my mind in favor of 3.0 without full/any JPA: 1. Lack of momentum. We were unable to find any committed volunteers to work on the JPA provider, even though we had maybe 5 or 6 declared volunteers, so I ended up doing all work myself. I have a few theories why, but this is not important for this discussion. 2. My personal availability to do Cayenne work has shrunk significantly with growing ObjectStyle consulting business. The remaining time is spent on Cayenne classic API, driven by user requests and my own needs. 3. The amount of new features developed in Cayenne classic in 3.0 requires some serious catching up to do - add modeler support for many new features, write tutorials and documentation. In this respect I think one thing is very important - communicate to our users a clear definition of what is Cayenne now (i.e. the scope of fully supported features, best practices, etc.). We've done that pretty well in the past, but it is impossible to do it with a moving target. There are questions being asked like is there POJO support?, how do I configure cache, etc. All we can do is give a vague answer it sorta work, there's no modeler or documentation). With the amount of cool new stuff, I wish we could give users more definite answers (or maybe I am too backwards thinking, and in the post-Web 2.0 world everybody is comfortable using nightly builds in production, and we are wasting time with all the cleanup? :-)) Anyways... Regardless of the limited resources we've managed to advance Cayenne 3.0 very far, and regardless of the lack of docs for the new features, people love and use them already, so there are lots of things to be proud of: http://cayenne.apache.org/doc/guide-to-30-features.html So here is the suggested plan. The development part of it is presented from the POV of Andrus as a Cayenne committer (i.e. the stuff I will be working on that does not require PMC consensus and does not require others to follow). Release plan part will require the PMC consensus. DEVELOPMENT: JPA is still on the table, only postponed till the future releases (3.1). For now concentrate on wrapping up classic API features. Here is an approximate (and pretty long) list: * EJBQL missing features (constructors, flattened relationships, better error reporting) * Vertical Inheritance * Multiple cayenne.xml in the project (CAY-943) * Generating Query and Procedure Access Code (CAY-1070) * Modeler SoC 2008 * Modeler: support for embeddables * Modeler: support for EJBQL queries * Tutorials * Resolve JPA legal caveat [1] * (plus lots of smaller features and bug fixes) : RELEASE PLAN: * Once major remaining features are in, we change releases suffix from Mx to Bx (milestone to beta) and go into the code freeze. * Once we fix all bugs and write docs, we do release candidates (somewhere here we also branch for 3.1 development) * We release 3.0-final * We EOL 1.2 (SourceForge) and 2.0 (Apache) branches. Thoughts? Andrus [1] JPA Legal Caveat: (something to confirm on legal-discuss). We are not allowed to release a JPA provider until it fully passes the TCK. Per some interpretations of the JPA spec license it seems to mean that we can't release a 3.0-final that contains JPA-nonfinal provider jars (while we can still release milestone non-final releases of JPA). So we'll likely have to fork JPA stuff in a separate assembly. That's a minor detail IMO. We can easily comply.
oracle anyone?
Hello. I currently have access to PostgreSQL, Derby, hsql, MySQL and MS SQL Server. I really want to be able to run junit tests on some more databases like Oracle, DB2 and so on. Anyone know how we can set that up? Regards, - Tore.
[jira] Commented: (CAY-1063) Derby adapter is not able to remove NOT NULL relationship
[ https://issues.apache.org/cayenne/browse/CAY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12926#action_12926 ] Tore Halset commented on CAY-1063: -- I do not have access (easily) to MS SQL Server these days, but will look at it later. If you are in a hurry, please run the junit tests and patch SQLServerMergerFactory if needed. http://cayenne.apache.org/running-unit-tests.html Derby adapter is not able to remove NOT NULL relationship - Key: CAY-1063 URL: https://issues.apache.org/cayenne/browse/CAY-1063 Project: Cayenne Issue Type: Bug Components: Cayenne Core Library Affects Versions: 3.0 Environment: Does Derby even support this operation? Reporter: Øyvind Harboe Assignee: Tore Halset Priority: Minor Fix For: 3.0 31000 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - Detected and installed adapter: org.apache.cayenne.dba.derby.DerbyAdapter 45641 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - ALTER TABLE log_email ALTER COLUMN sender DROP NOT NULL 45704 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - *** error. java.sql.SQLException: Syntax error: Encountered DROP at line 1, column 43. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.cayenne.merge.ExecutingMergerContext.executeSql(ExecutingMergerContext.java:60) at org.apache.cayenne.merge.AbstractToDbToken.execute(AbstractToDbToken.java:41) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CAY-1063) Derby adapter is not able to remove NOT NULL relationship
[ https://issues.apache.org/cayenne/browse/CAY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset closed CAY-1063. fixed and note added to RELEASE-NOTES.txt Derby adapter is not able to remove NOT NULL relationship - Key: CAY-1063 URL: https://issues.apache.org/cayenne/browse/CAY-1063 Project: Cayenne Issue Type: Bug Components: Cayenne Core Library Affects Versions: 3.0 Environment: Does Derby even support this operation? Reporter: Øyvind Harboe Assignee: Tore Halset Priority: Minor Fix For: 3.0 31000 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - Detected and installed adapter: org.apache.cayenne.dba.derby.DerbyAdapter 45641 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - ALTER TABLE log_email ALTER COLUMN sender DROP NOT NULL 45704 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - *** error. java.sql.SQLException: Syntax error: Encountered DROP at line 1, column 43. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.cayenne.merge.ExecutingMergerContext.executeSql(ExecutingMergerContext.java:60) at org.apache.cayenne.merge.AbstractToDbToken.execute(AbstractToDbToken.java:41) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CAY-671) custom exception class for ROP missing session
[ https://issues.apache.org/cayenne/browse/CAY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset reassigned CAY-671: --- Assignee: (was: Tore Halset) custom exception class for ROP missing session -- Key: CAY-671 URL: https://issues.apache.org/cayenne/browse/CAY-671 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Reporter: Tore Halset Priority: Minor Fix For: 3.0 Currently BaseRemoteService are throwing a CayenneRuntimeException if the session are missing. It would be better if this was a subclass of CRE as it would make it easier for the ROP client to detect this situation and perhaps reconnect. My proposal is to add org/apache/cayenne/remote/MissingSessionException as a subclass of CRE and throw it from BaseRemoteService. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAY-671) custom exception class for ROP missing session
[ https://issues.apache.org/cayenne/browse/CAY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924#action_12924 ] Tore Halset commented on CAY-671: - could someone using ROP actively take over this issue? custom exception class for ROP missing session -- Key: CAY-671 URL: https://issues.apache.org/cayenne/browse/CAY-671 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Reporter: Tore Halset Assignee: Tore Halset Priority: Minor Fix For: 3.0 Currently BaseRemoteService are throwing a CayenneRuntimeException if the session are missing. It would be better if this was a subclass of CRE as it would make it easier for the ROP client to detect this situation and perhaps reconnect. My proposal is to add org/apache/cayenne/remote/MissingSessionException as a subclass of CRE and throw it from BaseRemoteService. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CAY-981) merge: faster junit tests
[ https://issues.apache.org/cayenne/browse/CAY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset closed CAY-981. --- Resolution: Fixed Sounds like current speed is acceptable. Otherwise, please reopen. merge: faster junit tests - Key: CAY-981 URL: https://issues.apache.org/cayenne/browse/CAY-981 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Affects Versions: 3.0 Reporter: Tore Halset Assignee: Tore Halset Fix For: 3.0 Andrus reported that the junit tests takes more than 1.5 hour on oracle after the merge-stuff was added. This caused by too much use of DbLoader. Is is also slow on PostgreSQL and MySQL. http://objectstyle.org/cayenne/lists/cayenne-devel/2008/01/0219.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAY-1063) Derby adapter is not able to remove NOT NULL relationship
[ https://issues.apache.org/cayenne/browse/CAY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899#action_12899 ] Tore Halset commented on CAY-1063: -- Ari: the case here is to drop a not null constraint, not to add it. Derby adapter is not able to remove NOT NULL relationship - Key: CAY-1063 URL: https://issues.apache.org/cayenne/browse/CAY-1063 Project: Cayenne Issue Type: Bug Components: Cayenne Core Library Affects Versions: 3.0 Environment: Does Derby even support this operation? Reporter: Øyvind Harboe Assignee: Andrus Adamchik Priority: Minor 31000 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - Detected and installed adapter: org.apache.cayenne.dba.derby.DerbyAdapter 45641 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - ALTER TABLE log_email ALTER COLUMN sender DROP NOT NULL 45704 [SocketListener0-9] INFO org.apache.cayenne.access.QueryLogger - *** error. java.sql.SQLException: Syntax error: Encountered DROP at line 1, column 43. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) at org.apache.cayenne.merge.ExecutingMergerContext.executeSql(ExecutingMergerContext.java:60) at org.apache.cayenne.merge.AbstractToDbToken.execute(AbstractToDbToken.java:41) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 3.0 M4 Release Vote
+1 Regards, - Tore. On 18. mai. 2008, at 18.05, Kevin Menard wrote: 3.0M4 has been a long time coming. We've got a lot of new features and important bug fixes added. I've prepared assemblies for Windows, Mac, and others here: http://people.apache.org/~kmenard/release/3.0M4/ Please test them out and vote for the release accordingly. Here's my +1 for the release. -- Kevin
server-to-client event push - Re: relationship query and cache refreshing in 3tier cayenne
Hello. On 14. mai. 2008, at 00.46, Andrus Adamchik wrote: (2) Setup server-to-client event push. I did that in the past with a always-on XMPP connection in parallel with the main HTTPS data channel (I know it worked for object updates... it needs to be extended to cache groups invalidation). For a long time I wanted to investigate Jetty Continuations (and more generally, queuing events on the server for each live client, and letting client frequently poll for events). This would allow to reuse the main ROP connection, but this needs to be developed yet. It looks like the thing Jetty are doing with Continuations will be standardized in Servlet 3.0 http://blogs.webtide.com:80/gregw/2008/04/28/1209355449829.html Regards, - Tore.
Re: Hello list!
Hello and welcome! It is like everything around me happens in St.- Petersburg now. Really strange. Regards, - Tore. On May 6, 2008, at 18:49, Andrey Razumovsky wrote: Hi all Cayenne Developers! My name is Andrey Razumovsky, i'm from St.-Petersburg, Russia. I am glad to announce that i will be participate here as a Google Summer of Code student. My email is [EMAIL PROTECTED] and my ICQ number is 360531483. Hope we will all benefit from our cooperation! Regards, Andrey
Re: M4?
Agree. I will be able to join in after 2000 CET or 1800 UTC almost every day. - Tore. On 23. april. 2008, at 09.35, Andrus Adamchik wrote: I think M4 is long overdue. Just these two issues warrant a release - CAY-984, CAY-999, and we have so much more. I still hope to squeeze a few more bug fixes in it, but I feel like we need to release the next milestone rather sooner than later. Andrus
Re: [CONF] Apache Cayenne: RESTful Cayenne XML Service (page edited)
Hello.
Interesting subject. I am working on GIS services, and there have been
some good discussion lately around RESTful feature services.
Some ideas:
* Fetching a single entity could be done without query parameters.
Ala. http://localhost/myapp/cayennexml/entity/Person/1 for person with
id 1.
* Updating a person object could be done by POST to the same url.
* Creating a person object could be done by PUT to something like
http://localhost/myapp/cayennexml/entity/Person/
* Perhaps query for a single entity could be done in the entities
namespace? ala http://localhost/myapp/cayennexml/entity/Person?q=mypersonqueryname=Tore
Hope I am not disturbing.
Regards,
- Tore.
On Apr 15, 2008, at 18:31, [EMAIL PROTECTED] wrote:
Page Edited : CAY : RESTful Cayenne XML Service
RESTful Cayenne XML Service has been edited by Andrus Adamchik (Apr
15, 2008).
(View changes)
Content:
The idea is to build a service that generates XML for persistent
data based on some criteria, passed as a URL with parameters. The
service would use Cayenne to run the queries and XML generation
process would leverage DataMap information as much as possible. The
service should allow arbitrary customization of the generated XML
format. The service should allow to run user code at all points of
the request lifecycle, e.g. to implement security, filter the
results, customize XML, etc. At the same time, the service should be
usable out of the box with no other configuration except for the
cayenne.xml and friends.
Addressing The Queries
The service is RESTful in that each request is uniquely identified
by the URL parameters. E.g.:
http://localhost/myapp/cayennexml?q=myqueryp1=ap2=b
q is a reserved parameter corresponding to the mapped query name.
Other parameters are treated as named parameters that should be
passed to the query. (TODO: type conversion)
XML Serialization
Default XML format will be auto-generated from Cayenne mapping and
can be overridden by the user (e.g. certain tags can be renamed,
excluded, etc.). Cayenne DataObject-to-XML generator will be used,
and users would optionally specify a config file overriding the
defaults for XML generation.
Including Relationships in XML
Service callers can not specify which relationships to include, as
this would result in a security hole. Instead the default behavior
is to look at the query prefetches to see what parts of object graph
should be included in the output XML. (TODO: in the future we may
allow specifying included relationships separately from the query
prefetches).
Interceptors
The service would allow registering a chain of interceptors that
would allow implementing custom processing logic at all points of
the invocation lifecycle. E.g.:
public interface XMLServiceInterceptor {
void onRequest(XMLServiceChain chain, XMLEncoder out, ObjectContext
context, String queryName, MapString, String parameters);
}
Other Features
• Pagination. I.e. the ability to encode page size and page # in
the URL
Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07,
2006) - Bug/feature request
Unsubscribe or edit your notifications preferences
[jira] Created: (CAY-1033) merge: modeler should remove completed tokens
merge: modeler should remove completed tokens - Key: CAY-1033 URL: https://issues.apache.org/cayenne/browse/CAY-1033 Project: Cayenne Issue Type: Improvement Components: CayenneModeler GUI Affects Versions: 3.0 Reporter: Tore Halset Assignee: Tore Halset Priority: Trivial Fix For: 3.0 The tokens that are completed without any errors should be removed from the Migrate DB Schema: Options view. This makes it easier for users that want to apply some tokens at a time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CAY-1033) merge: modeler should remove completed tokens
[ https://issues.apache.org/cayenne/browse/CAY-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset resolved CAY-1033. -- Resolution: Fixed merge: modeler should remove completed tokens - Key: CAY-1033 URL: https://issues.apache.org/cayenne/browse/CAY-1033 Project: Cayenne Issue Type: Improvement Components: CayenneModeler GUI Affects Versions: 3.0 Reporter: Tore Halset Assignee: Tore Halset Priority: Trivial Fix For: 3.0 The tokens that are completed without any errors should be removed from the Migrate DB Schema: Options view. This makes it easier for users that want to apply some tokens at a time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CAY-1033) merge: modeler should remove completed tokens
[ https://issues.apache.org/cayenne/browse/CAY-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset closed CAY-1033. merge: modeler should remove completed tokens - Key: CAY-1033 URL: https://issues.apache.org/cayenne/browse/CAY-1033 Project: Cayenne Issue Type: Improvement Components: CayenneModeler GUI Affects Versions: 3.0 Reporter: Tore Halset Assignee: Tore Halset Priority: Trivial Fix For: 3.0 The tokens that are completed without any errors should be removed from the Migrate DB Schema: Options view. This makes it easier for users that want to apply some tokens at a time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAY-981) merge: faster junit tests
[ https://issues.apache.org/cayenne/browse/CAY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12813#action_12813 ] Tore Halset commented on CAY-981: - I have commited a fix that limits DbLoader to only analyze actual tables for the junit tests. This speed up execution on PostgreSQL, but I do not know about Oracle and MySQL. merge: faster junit tests - Key: CAY-981 URL: https://issues.apache.org/cayenne/browse/CAY-981 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Affects Versions: 3.0 Reporter: Tore Halset Assignee: Tore Halset Fix For: 3.0 Andrus reported that the junit tests takes more than 1.5 hour on oracle after the merge-stuff was added. This caused by too much use of DbLoader. Is is also slow on PostgreSQL and MySQL. http://objectstyle.org/cayenne/lists/cayenne-devel/2008/01/0219.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Unit Test Slowness [Re: 3.0 M3 test results]
Hello.
(sorry for answering an old post)
I did not get any feedback on this one, but have commited it to trunk.
Please comment Oracle results on https://issues.apache.org/cayenne/browse/CAY-981
Regards,
- Tore.
On Jan 30, 2008, at 00:13, Tore Halset wrote:
Hello.
I have looked at this, but are not really able to reproduce the
problem as I do not have access to Oracle. Even if I had, there is
6+ years since I used Oracle.. Makes me feel old :/
My first attempt is to reduce the work for DbLoader by specifying a
the tables that should be tested. I have done this by adding a
overridable method called includeTableName(String) that defaults to
true. It is not very elegant, but might work.
Could you please try the attached patch on oracle Andrus?
Regards,
- Tore.
On Jan 28, 2008, at 23:00, Andrus Adamchik wrote:
I finally found time to run unit tests of the M3 tag on various
DB's (evaluating release artifacts is next on my list) I'll
post the results in a little bit (so far all good), but I wanted to
comment on the merge test case slowness.
Because of repeated DB metadata access via DbLoader I noticed a bit
of slowdown on MySQL. Then I started testing on Oracle, and this
one is a bummer. My unit tests are already running for about 50
minutes with no end in sight... So maybe there is a way to cache
the DbLoader calls for the purpose of unit testing? Would be nice
if we could optimize that on trunk.
Index: framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/
cayenne/merge/DbMerger.java
===
--- framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/
cayenne/merge/DbMerger.java (revision 616534)
+++ framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/
cayenne/merge/DbMerger.java (working copy)
@@ -53,8 +53,12 @@
public class DbMerger {
private MergerFactory factory;
-
-public boolean includeTableName(String tableName){
+
+/**
+ * A method that return true if the given table name should be
included. The default
+ * implemntation include all tables.
+ */
+public boolean includeTableName(String tableName) {
return true;
}
@@ -82,7 +86,15 @@
try {
conn = dataSource.getConnection();
-DbLoader dbLoader = new DbLoader(conn, adapter, new
LoaderDelegate());
+final DbMerger merger = this;
+DbLoader dbLoader = new DbLoader(conn, adapter, new
LoaderDelegate()) {
+
+@Override
+public boolean includeTableName(String tableName) {
+return merger.includeTableName(tableName);
+}
+};
+
DataMap detectedDataMap = dbLoader.loadDataMapFromDB(
null,
null,
@@ -94,7 +106,7 @@
for (DbEntity dbEntity : dataMap.getDbEntities()) {
String tableName = dbEntity.getName();
-if(!includeTableName(tableName)){
+if (!includeTableName(tableName)) {
continue;
}
@@ -119,7 +131,7 @@
// TODO: support drop table. currently, too many tables
are marked for drop
for (DbEntity e : dbEntityToDropByName.values()) {
-if(!includeTableName(e.getName())){
+if (!includeTableName(e.getName())) {
continue;
}
@@ -258,6 +270,11 @@
// relationships to add
for (DbRelationship rel : dbEntity.getRelationships()) {
+
+if (!includeTableName(rel.getTargetEntityName())) {
+continue;
+}
+
if (findDbRelationship(detectedEntity, rel) == null) {
// TODO: very ugly. perhaps MergerToken should have
a .isNoOp()?
AbstractToDbToken t = (AbstractToDbToken) factory
Index: framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/
cayenne/access/DbLoader.java
===
--- framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/
cayenne/access/DbLoader.java (revision 616534)
+++ framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/
cayenne/access/DbLoader.java (working copy)
@@ -165,6 +165,14 @@
public DbAdapter getAdapter() {
return adapter;
}
+
+/**
+ * A method that return true if the given table name should be
included. The default
+ * implemntation include all tables.
+ */
+public boolean includeTableName(String tableName) {
+return true;
+}
/**
* Retrieves catalogues for the database associated with this
DbLoader.
@@ -284,6 +292,10 @@
if (name == null || name.startsWith(BIN$)) {
continue;
}
+
+if (!includeTableName(name)) {
+continue;
+}
Table info
[jira] Commented: (CAY-289) Implement Quoting of identifiers
[ https://issues.apache.org/cayenne/browse/CAY-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12753#action_12753 ] Tore Halset commented on CAY-289: - For PostgresSQL (at least) this behavior should be optional. In our project we do not care about the case of the column and table names. They are upper-case in the model. If cayenne would start using around each column and table name, then we would have to change all of our tables and columns to be created with as well. And that is a lot of work for nothing! It would not help to change to lowercase in the model as that would break other databases. Still for PostgreSQL: create table A; select * from A does not work as the table name is a. Implement Quoting of identifiers Key: CAY-289 URL: https://issues.apache.org/cayenne/browse/CAY-289 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Affects Versions: 1.2 [STABLE] Environment: Linux, Sun JDK1.5, MS SQL Server 2000, jtds-1.0, Croatian locale Reporter: Tomislav Nakic-Alfirevic Assignee: Andrus Adamchik Fix For: 3.0 Say a table t0 has an attribute my attrib 0. You correct the obj-attribute to, for instance, my_attrib_0, but the db-attribute is still my attrib 0. When you try to run a query on t0, the generated query looks like: SELECT ..., t0.my attrib 0, ... FROM dbo.t0 AS t0 This, obviously, can't possibly work. The correct SQL would be: SELECT ..., t0.[my attrib 0], ... FROM dbo.[t0] AS t0 Notice the square brackets arround the attributes and table names: that makes the string a valid attribute or table name valid. A further improvement might be to add the database name: SELECT ..., t0.[my attrib 0], ... FROM [dbname].dbo.[t0] AS t0 I mention it because I use the quantum plugin as a database access plugin and it complained about a table called dbo.tablename (as I believe it should) and all was well when I used mydbname.dbo.tablename. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
newbie callback questions
Hello.
I just tried callbacks for the first time. I wanted to update a
modified field every time a data object was changed. In the modeler I
added a method called onPreUpdate of type pre-update for the entity.
Then I added the following method in the data object.
protected void onPreUpdate() {
setModified(new Date());
}
It seem to work very well. Is this the correct way to do it?
In my simple case it would have been even nicer if the _MyEntity.java
included something like protected abstract void onPreUpdate();
generated from the model. Default MyEntity.java should include an emty
stub for that method.
Would that be a reasonable feature request? I am asking before
registering as I am such a callback newbie.
In modeler, the difference between callbacks and listeners are a bit
confusing. Anyone having some ideas to how this interface could be
clearer/simpler?
Regards,
- Tore.
Re: VOTE: 3.0M3 Release
Hello. On Jan 28, 2008, at 15:30, Kevin Menard wrote: http://people.apache.org/~kmenard/release/3.0M3/ Please test out the binaries and then cast your vote. Thanks for doing the release Kevin! Here is my testing: * used the .tar.gz with our project junit tests. no errors found. * cayenne junit tests on derby and psql * downloaded the mac dmg and played with the modeler My vote: +1 On a side note: Some months ago we moved our production system (using cayenne all over) from MS SQL Server to PostgreSQL for performance and concurrency reasons. The worst case commit was reduced from 20 minutes locking the important table for everyone to about 20 seconds with no locking issues. All on ca the same hardware. This week, we got a new server and now, the same commit is around 1 second :). It is a Dell 2900 with 10 15Krpm SAS discs. We use 2 for OS++, 2 for psql wal and 6 in a raid 10 for the base. Not that big, but a step up for us. Regards, - Tore.
Re: 3.0 M3 test results
On Jan 29, 2008, at 11:40, Andrus Adamchik wrote: Derby - lots of failures (IIRC Tore is working on resolving those on trunk?) I have upgraded derby in pom.xml on trunk. That fixed the merge- problems, but there are still some tests for derby that failes for me. testDifferentEntity (org.apache.cayenne.access.DataContextEJBQLSubqueryTest) testExists(org.apache.cayenne.access.DataContextEJBQLSubqueryTest) testBinaryPK2(org.apache.cayenne.dba.PkGeneratorTest) Oracle - got stuck because of slow DbLoader operation, I had to terminate the test after 1.5 hours This is horrible. Sorry guys! At least 50% of the DbLoader operations is to check that the previous DbLoader went well. I should probably only test jdbc metadata for the actual tables instead of the complete db. That could speed things up. I have registered this in JIRA. https://issues.apache.org/cayenne/browse/CAY-981 - Tore.
[JIRA] Closed: (CAY-980) upgrade derby
[ https://issues.apache.org/cayenne/browse/CAY-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset closed CAY-980. --- Resolution: Fixed fixed in trunk and added to RELEASE-NOTES.txt for M4 upgrade derby - Key: CAY-980 URL: https://issues.apache.org/cayenne/browse/CAY-980 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Affects Versions: 3.0 Reporter: Tore Halset Assignee: Tore Halset Fix For: 3.0 Current maven pom.xml asks for derby 10.2.2.0. This is a problem for some of the merge junit tests as alter table ... drop column ... was added in derby 10.3. 10.2.2.0 is from december 2006 and the first 10.3 is from august 2007. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[JIRA] Created: (CAY-980) upgrade derby
upgrade derby - Key: CAY-980 URL: https://issues.apache.org/cayenne/browse/CAY-980 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Affects Versions: 3.0 Reporter: Tore Halset Assignee: Tore Halset Fix For: 3.0 Current maven pom.xml asks for derby 10.2.2.0. This is a problem for some of the merge junit tests as alter table ... drop column ... was added in derby 10.3. 10.2.2.0 is from december 2006 and the first 10.3 is from august 2007. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 3.0 M3 test results
On Jan 26, 2008, at 00:05, Tore Halset wrote: On Jan 25, 2008, at 22:34, Kevin Menard wrote: PostgreSQL 8.2: FAIL (74 failed tests) Here, only(?) one failed. It was merge.CreateTableToModelTest.testAddTable. I am looking into that one now. It was one of those issues with lower case table names in PostgreSQL. I have fixed it in trunk (r615410). Did you do a createlang plpgsql databasename? I got fooled by that one before. Derby: FAIL (9 failed tests) Oups, mostly merging. I'll have to work on this.. pom.xml asks for derby 10.2.2.0. alter table ... drop column ... was added in derby 10.3. 10.2.2.0 is from december 2006 and the first 10.3 is from august 2007. Would it be ok to bump up to derby 10.3 for trunk? After upgrading to 10.3 (locally) and patching some small issues in trunk (r615405), I got the merging part of derby running. Only(?) the following 3 issues left with derby. testDifferentEntity (org.apache.cayenne.access.DataContextEJBQLSubqueryTest) testExists(org.apache.cayenne.access.DataContextEJBQLSubqueryTest) testBinaryPK2(org.apache.cayenne.dba.PkGeneratorTest) I think we should go for Derby 10.3. - Tore.
Re: 3.0 M3 test results
On Jan 25, 2008, at 22:34, Kevin Menard wrote: Mac OS X (Java 1.5) Same as mine. PostgreSQL 8.2: FAIL (74 failed tests) Here, only(?) one failed. It was merge.CreateTableToModelTest.testAddTable. I am looking into that one now. Did you do a createlang plpgsql databasename? I got fooled by that one before. Derby: FAIL (9 failed tests) Oups, mostly merging. I'll have to work on this.. For example, I see a lot of messages about duplicate PK tables coming from org.apache.cayenne.merge.ExecutingMeregContext#executeSql():60 I am using PkGenerator.createAutoPkStatements. This method returns CREATE TABLE AUTO_PK_SUPPORT (for some adapters) even though the table allready exist. It should be possible to create the table if it exist, otherwise just insert the missing rows. For adapters using sequences, this should not be the problem. The merging still works fine, so this is not a blocker for me. I will however look into it. - Tore.
Re: 3.0 M3 test results
On Jan 26, 2008, at 01:08, Kevin Menard wrote: On 1/25/08 6:05 PM, Tore Halset [EMAIL PROTECTED] wrote: PostgreSQL 8.2: FAIL (74 failed tests) Here, only(?) one failed. It was merge.CreateTableToModelTest.testAddTable. I am looking into that one now. Did you do a createlang plpgsql databasename? I got fooled by that one before. That did the trick. I had reformatted my machine after my botched Leopard upgrade. I'll make a note in the developer's guide. The one failed test I have seems to be related to merge stuff: Fixed in trunk and M3. Derby: FAIL (9 failed tests) Oups, mostly merging. I'll have to work on this.. Great. I'll hold up. Fixed in trunk and M3, but need us to upgrade derby as well. - Tore.
[JIRA] Resolved: (CAY-966) ObjRelationsship's are not removed processing DropColumnToModel
[
https://issues.apache.org/cayenne/browse/CAY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tore Halset resolved CAY-966.
-
Resolution: Fixed
ObjRelationsship's are not removed processing DropColumnToModel
---
Key: CAY-966
URL: https://issues.apache.org/cayenne/browse/CAY-966
Project: Cayenne
Issue Type: Bug
Components: Cayenne Core Library
Affects Versions: 3.0
Environment: all
Reporter: Øyvind Harboe
Assignee: Tore Halset
Attachments: DbEntity.java, DropColumnToModel.java,
DropColumnToModel.java, surefire-reports.zip
I'll attatch a modified DbEntity.java that fixes the problem here
Basically the code below won't work right because the ObjRelationship's
aren't removed.
MergerContext mergerContext = new
ExecutingMergerContext(
payBackDataMap, dataNode);
for (MergerToken token : tokens)
{
if (token.getDirection() ==
MergeDirection.TO_DB)
{
token =
token.createReverse(dataNode.getAdapter()
.mergerFactory());
}
token.execute(mergerContext);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[JIRA] Closed: (CAY-966) ObjRelationsship's are not removed processing DropColumnToModel
[
https://issues.apache.org/cayenne/browse/CAY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tore Halset closed CAY-966.
---
ObjRelationsship's are not removed processing DropColumnToModel
---
Key: CAY-966
URL: https://issues.apache.org/cayenne/browse/CAY-966
Project: Cayenne
Issue Type: Bug
Components: Cayenne Core Library
Affects Versions: 3.0
Environment: all
Reporter: Øyvind Harboe
Assignee: Tore Halset
Attachments: DbEntity.java, DropColumnToModel.java,
DropColumnToModel.java, surefire-reports.zip
I'll attatch a modified DbEntity.java that fixes the problem here
Basically the code below won't work right because the ObjRelationship's
aren't removed.
MergerContext mergerContext = new
ExecutingMergerContext(
payBackDataMap, dataNode);
for (MergerToken token : tokens)
{
if (token.getDirection() ==
MergeDirection.TO_DB)
{
token =
token.createReverse(dataNode.getAdapter()
.mergerFactory());
}
token.execute(mergerContext);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[JIRA] Assigned: (CAY-978) Add getEntity/getColumn to AddColumnToDb
[ https://issues.apache.org/cayenne/browse/CAY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset reassigned CAY-978: --- Assignee: Tore Halset (was: Andrus Adamchik) Add getEntity/getColumn to AddColumnToDb Key: CAY-978 URL: https://issues.apache.org/cayenne/browse/CAY-978 Project: Cayenne Issue Type: Improvement Reporter: Øyvind Harboe Assignee: Tore Halset Attachments: AddColumnToDb.java When I add a certain column, I need to perform a conversion. I need to know which entity + column is being added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[JIRA] Commented: (CAY-978) Add getEntity/getColumn to AddColumnToDb
[ https://issues.apache.org/cayenne/browse/CAY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12719#action_12719 ] Tore Halset commented on CAY-978: - added to all relevant tokens Add getEntity/getColumn to AddColumnToDb Key: CAY-978 URL: https://issues.apache.org/cayenne/browse/CAY-978 Project: Cayenne Issue Type: Improvement Reporter: Øyvind Harboe Assignee: Tore Halset Attachments: AddColumnToDb.java When I add a certain column, I need to perform a conversion. I need to know which entity + column is being added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[JIRA] Assigned: (CAY-975) Add MergerToken to update database or model with PK Generation Strategy
[ https://issues.apache.org/cayenne/browse/CAY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tore Halset reassigned CAY-975: --- Assignee: Tore Halset (was: Andrus Adamchik) Add MergerToken to update database or model with PK Generation Strategy --- Key: CAY-975 URL: https://issues.apache.org/cayenne/browse/CAY-975 Project: Cayenne Issue Type: Improvement Components: Cayenne Core Library Affects Versions: 3.0 Reporter: Øyvind Harboe Assignee: Tore Halset I'm using DbMerger to update the DataMap with attributes from the database. This solves a raft of problems, including how to let database managers modify length of fields from e.g. SQL Manager(which they are comfortable with). My DataMap states that the pk is generated by the database, but when that is not the case I'll get this exception: Caused by: java.sql.SQLException: Cannot insert the value NULL into column 'user_id', table 'qpb.dbo.users'; column does not allow nulls. INSERT fails. at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:364) at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2754) at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2195) at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:620) at net.sourceforge.jtds.jdbc.JtdsStatement.processResults(JtdsStatement.java:483) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MissingSessionException
On Jan 22, 2008, at 12:01 , Andrus Adamchik wrote: If this exception is to be caught on the client (and if it works), I suggest we move it to the org.apache.cayenne.remote package to indicate that it needs to be present on both server and client. That would be great. I would prefer someone else (than me) fixing this as I do not have any java ROP client. - Tore. Andrus On Jan 22, 2008, at 10:30 AM, Tore Halset wrote: Hello. I think I added MissingSessionException on the serverside to support the cocoa client. It is working for the cocoa client, but I do not think I tested it with a normal java ROP client. - Tore. On Jan 22, 2008, at 9:17 , Aristedes Maniatis wrote: OK, I've got one more client/server issue which arose when I upgraded our code to 3.0M3 and used the server/client Cayenne jars (I previously had the full jar at both ends). org.apache.cayenne.remote.service.MissingSessionException is not available on the client. We use it on the client like this to detect a lost connection: if (e.getCause() instanceof MissingSessionException) but this has never actually worked, so perhaps I've misunderstood its purpose. * should this be available on the client? I'd think that any exception which might be propagated across Hessian should be available on the client. * should it be working as I've used above? Cheers Ari -- ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
