Re: Adding enums?
Yeah, I never use it at all.
On Sep 23, 2009, at 5:44 PM, Michael Gentry wrote:
BTW, I'm a little iffy on the static import stuff. It seems less
explicit and somewhat cheating to me, but I'm just tossing the idea
out for feedback.
On Wed, Sep 23, 2009 at 10:40 AM, Michael Gentry > wrote:
If wanting to keep things shorter, couldn't you do a static import?
I'm a little rusty on the syntax, but wouldn't it be something like:
import static ...query.QueryDirection.*;
Ordering ordering = new Ordering("artistName", ASCENDING);
Hmm, or maybe that only works for static constants and not enums.
I'd
have to test that.
mrg
On Wed, Sep 23, 2009 at 10:34 AM, Andrus Adamchik
wrote:
+1
If we can do clean gradual deprecation of the old API. Also I like
us using
ASCENDING instead of ASC, as you proposed, but wonder if we can call
OrderingDirection something shorter, just to keep things tight.
Another candidate for such refactoring is PersistenceState. Maybe
create a
"State" enum or "PersistentState"?
Andrus
On Sep 23, 2009, at 5:24 PM, Michael Gentry wrote:
Should we add more enums to the code? For example, in
Ordering.java,
there are these constants:
public static final boolean ASC = true;
public static final boolean DESC = false;
However, there is no enum to represent the options. The
constructors look
like:
public Ordering(String sortPathSpec, boolean ascending) ...
There is nothing to encourage/enforce the usage of the constants,
so
you tend to see "true" and "false" being used. Even in our
documentation:
http://cayenne.apache.org/doc/using-orderings.html
query.addOrdering("artistName", true);
Ordering ordering = new Ordering("artistName", true);
To the new (or even experienced) user, seeing "true" there tends to
have no meaning. I (and some of the people I've been showing
Cayenne
to here) would rather see something like:
Ordering ordering = new Ordering("artistName",
OrderingDirection.ASCENDING);
One guy even suggested something like:
Ordering ordering = new AscendingOrdering("artistName");
That is more concise and still explicit, but would obviously
require
even more code changes (probably). Especially when adding the case
insensitive stuff.
Thoughts?
Thanks!
mrg
Re: Adding enums?
On Sep 23, 2009, at 6:09 PM, Michael Gentry wrote: #1: Call the enum class Order. I think Order.ASCENDING would be readable and intuitive. +1 #2: Keep it something more descriptive like OrderingDirection, but in the Ordering class have a "public static final OrderingDirection ASCENDING = OrderingDirection.ASCENDING;". Then you could reference Ordering.ASCENDING (kind of like Ordering.ASC). This seems awkward, though, but makes it similar to what is already there. Don't understand this one. Why the new Order enum is not sufficient? Andrus
Re: Making sense of callbacks
Hi Andrey, Thanks for your comments. This made me tweak my initial suggestion, resulting in something that hopefully makes more sense. So here is an attempt to show the full callback picture with suggested changes (grouping things by the object pre-commit state): COMMITTED: postLoad NEW: prePersist (called after registration in context) preInsert (POTENTIAL NEW CALLBACK; called before commit) [1] postPersist (called after commit) MODIFIED: preUpdate (called before commit) postUpdate (called after commit) DELETED: preRemove (called before deleting in context, and before delete rules are evaluated) preUpdate (POTENTIAL REMOVED CALLBACK; called before commit) [2] postRemove (called after commit) postUpdate (POTENTIAL REMOVED CALLBACK; called after commit) [3] [1] We definitely need this callback here for the new objects right before commit. My suggestion of reusing "preUpdate" here was based on the fact that all my pre-commit code for NEW and MODIFIED objects is exactly the same, so it seems that from implementation standpoint the event is almost identical. On the other hand, "postUpdate" is indeed redundant for NEW objects. So using pre/postUpdate for NEW does break the symmetry... [2] While there's no overlap with a real "preUpdate" in possible callback functionality here, and we need to remove this one, this leaves a gap (just like with NEW objects) that needs to be filled with some "preCommitDeleted" callback. [3] Definitely needs to be removed. It is being passed TRANSIENT objects and is really out of place (though still JPA compatible :-)). I guess completely renaming callbacks to be aligned with Cayenne (rather than JPA) lifecycle could be a good thing (persist -> insert| create, remove -> delete, etc.), and may go a long way in clarifying what is called and when. It is the end of a long day here, so I am not ready to suggest any better naming right away, but regardless of the naming, if we just make the changes above, I think we can provide the existing users a clear set of instructions on how to migrate existing callbacks to the new set. FWIW I'll be able to try it myself on a large application without waiting for the B1 release. Andrus On Sep 23, 2009, at 8:53 PM, Andrey Razumovsky wrote: Hi Andrus, I also suffered missing "preInsert" listener a number of times. But, I think the moment of when listeners are called (and which of them are called) should be easily guessed by what is happening to the object. 1. call pre/postUpdate for new objects. So new objects will have pre/postPersist as well as pre/postUpdate callbacks. Of course the main motivation is that preUpdate is called before save, not after context insert, so all the relationships are in place. So there will be four calls in total at object creation. I don't think it is transparent that pre- and postUpdate will be called - after all, no updates are ever made! 2. stop calling pre/postUpdate for removed objects. This is causing grief when we need to access relationships of a deleted object. I'm confused. Are pre/postUpdate methods really called for deleted objects? If this is so, it definitely must be stopped I think. Only pre/ postRemove should be called.. What will be wrong if we just add new type of event - preInsert? Users aren't obligated to implement any listener class, after all. I'm afraid the changes you suggest will break a lot of existing code Thanks,
Re: Making sense of callbacks
Actually EntityManager.persist is the same as DataContext.registerObject. It does not commit to DB until "flush" is called or external transaction is committed. But the rest of the analysis is correct. So I am +1 on the following, even though there we'll end up with mismatch against JPA (Cayenne.postRegister == JPA.prePersist; Cayenne.prePersist != JPA.prePersist) : postRegister <- called when a non-persisted object is registered with a data context. You could even have a preRegister, but that's probably overkill. prePersist <- just before DB insert postPersist <- just after DB insert preUpdate < - just before DB update of existing object postUpdate <- just after DB update postLoad <- just after a committed obj. is fetched from the DB. Now wonder what we should do with "remove": preRemove <- just before DB delete postRemove <-just after DB delete There are 3 similar lifecycle points: (1) after object is deleted in context, (2) before deleted object is committed, (3) after deleted object is committed. Right now "preRemove" is called at (1). For symmetry we can call it at (2). But then we need another callback for (1). I just checked some of my use cases, and (1) is sort of an important place - you can make some assertions about the object before it is disassociated from its relationships via delete rules. I think I already figured out how to deal with my case, not sure how such removal of functionality would affect others? BTW, if all we do is callback renaming/adding new callbacks, we can provide DataMap migration ability via the Modeler. Andrus On Sep 24, 2009, at 6:08 AM, Robert Zeigler wrote: Hm. Apologies, I haven't been following this thread very closely. Preface: I realize JPA compatibility isn't necessarily a current goal, but hear me out. :) The way I read the JPA spec is that @PrePersist is supposed to be called immediately before database insert. The problem seems to be a mismatch between the "cayenne way" and the "JPA" way. In cayenne, you register your object, then make your changes (especially relationships), then commit to the DB. In JPA, you would setup the entire bean structure (including relationships) before calling EntityManager.persist, which results directly in a DB commit. Ie, persist is like context.registerNewObject() + context.commitChanges() rolled into one, except the scope is limited a single object and associated changes. I don't have any qualms about adding additional lifecycle listeners to make cayenne more useful in general and/or to address the impedence with JPA, but if we're going to keep lifecycle listeners with the same names as the JPA ones, we should also keep the same semantics, which means calling PrePersist immediately before insert. Otherwise, we'll confuse users new to cayenne but familiar with JPA. So, I would propose something more like: postRegister <- called when a non-persisted object is registered with a data context. You could even have a preRegister, but that's probably overkill. prePersist <- just before DB insert postPersist <- just after DB insert preUpdate < - just before DB update of existing object postUpdate <- just after DB update preRemove <- just before DB delete postRemove <-just after DB delete postLoad <- just after a committed obj. is fetched from the DB. Alternatively, as mentioned below we could rename all callbacks to align with the "cayenne way". But, again, if we're going to keep the JPA names, we should keep the behavior as JPA-like as possible. Robert
Re: Broken Mailing List Link
Thanks. Fixed. On Sep 25, 2009, at 12:01 PM, Dave Dombrosky wrote: There is a broken link on http://cayenne.apache.org/mailing-lists.html. The http://dir.gmane.org/gmane.comp.java.cayenne.dev link should be changed to http://dir.gmane.org/gmane.comp.java.cayenne.devel. -Dave
Re: Adding enums?
On Sep 25, 2009, at 5:27 PM, Michael Gentry wrote:
I've started looking into this. How about calling the sorting
direction enum Direction or SortOrder instead of Order? (I can see
people using an ORM having an Order class already, which might be a
bit confusing ... sorting your Orders by an Order ...) With the
change, you'd end up with a constructor something like:
public Ordering(String sortPathSpec, Direction/SortOrder
sortingDirection) {...}
I guess any of the above can potentially be an entity name, but I am
fine with either of the 3.
I think we should fix the case sensitive flag while we are at it.
Thoughts on the name for that one? Here is the constructor ...
public Ordering(String sortPathSpec, Direction/SortOrder
sortingDirection, boolean caseInsensitive) {...}
One option is to make the Direction/SortOrder enum look something
like:
public enum Direction/SortOrder {
ASCENDING, ASCENDING_INSENSITIVE, DESCENDING,
DESCENDING_INSENSITIVE
}
Then you don't need the third parameter.
Good idea.
Andrus
Re: Cayenne-trunk - Build # 465 - Still Failing
Seems the hudson install is still broken. All tests succeed on my machine. Hudson output is this: Parsing POMs ERROR: No classworlds*.jar found in /home/hudson/tools/maven/latest2 -- Is this a valid maven2 directory? Email was triggered for: Failure There are 1 triggered emails. Sending email for trigger: Failure Andrus On Sep 27, 2009, at 4:27 PM, Apache Hudson Server wrote: The Apache Hudson build system has built Cayenne-trunk (build #465) Status: Still Failing Check console output at http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/465/ to view the results.
Re: Changed PK Typecasting?
I don't recall an intentional change to disable automated type conversion. It was not supported before, so I guess it was purely coincidental that it worked on a particular database with a particular driver. Andrus On Sep 25, 2009, at 11:46 AM, Dave Dombrosky wrote: Trying to use the latest trunk code, I came across some behavior that has changed. I used to be able to pass DataObjectUtils.objectForPK a primary key that was a String, and Cayenne would automatically typecast this to the real PK type (such as String -> Integer). Now it seems like the typecasting does not occur, causing an exception on the query with my database. Was this change intentional? If not, I'll open a bug report with more detail. -Dave
Re: Making sense of callbacks
I am +1 on:
* Radical renaming if that helps us with consistency.
* The observation that pre/postCommit for NEW and MODIFIED objects are
often identical (in my use cases they are always identical). Wonder in
what case it is important to distinguish in postCommit whether the
object was new or modified before commit?
I am -1 on:
* Keeping two parallel sets of callbacks. The only purpose it serves
is compatibility with 3.0MN releases (N <= 6), and the need to
maintain it going forward outweighs it in my mind. Also triggering
callbacks is not free performance-wise, even for those events that
have no registered listeners, so extra callback types will
(marginally) slow things down. This will also allow us to use "pre/
post" prefixes for the names, as there won't parallel conflicting set
of callbacks.
* Mixing pre/postCommit for DELETED with NEW/MODIFIED. The object
state at the end of the commit is different (TRANSIENT for DELETED,
COMMITTED for NEW/MODIFIED), so callbacks are almost never the same.
I am +/-0 on:
* Callbacks on contexts. Could be a good idea to have listeners
attached to a context (although I don't see any use for context's own
callback methods). I suggest we keep that in mind, but push it to the
future releases to avoid adding new concepts to 3.0 at this point.
Conclusion:
So mixing Ari's idea with my points above, we have something like that:
* postLoad
* postAdd ("post" as it is invoked after object is added to the
context)
* preDelete ("pre" as it is invoked before delete rules are processed
and before the object state is changed)
* preCommit
* preCommitDeleted
* postCommit
* postCommitDeleted
... or we can go completely the Cayenne way and change the callback
signatures to take an enum characterizing the event nature, or even
some sort of an event object.
And another idea. Once we settle on the nature of the change on this
list, we write a migration guide draft for the users and take this
discussion to the user@ list to see if the wider community can uncover
any holes in the new design, or if there are other use cases that we
haven't thought of.
Andrus
On Sep 24, 2009, at 12:54 PM, Aristedes Maniatis wrote:
On 24/09/09 6:08 PM, Andrus Adamchik wrote:
So I am +1 on the following, even though there we'll end up with
mismatch against JPA (Cayenne.postRegister ==
JPA.prePersist; Cayenne.prePersist != JPA.prePersist)
Or, to take Robert's suggestion, we leave the existing callbacks in
place and don't touch them since they are the JPA terms. New stuff
can have brand new names.
To make a much more radical suggestion:
Working within the context:
onAddToContext [postRegister at the moment]
onRemoveFromContext [doesn't exist now, but seems symmetrical]
onDelete [deleted in context]
beforeCommit [preRemove, prePersist and preUpdate together]
afterCommit [postRemove, postPersist and postUpdate together]
onFetch [postLoad at the moment]
If we use words (like "commit") which already have meaning to
Cayenne users, then it is very clear what is going on and it
separates them from the JPA words. Then our docs have a little table
with two columns, showing where our terms match the JPA terms
exactly and where they differ. Avoiding "pre" and "post" completely
keeps our terms quite separate. Then we don't even need to deprecate
the JPA terms at all, just keep them as an 'alias' to Cayenne terms
where appropriate.
Let me explain my rationale for merging remove, persist and update.
It is easily possible within the callback itself to determine the
state of the object, so the user can write code which branches
appropriately. We find ourselves needing to link both persist and
update together anyway, because it is likely that the same code will
run for both. Next, the user action which caused the callback to
happen was commit(), so it just makes logical sense. Finally, it
means that the context itself can have its own beforeCommit and
afterCommit callbacks (with the same names so it all makes
consistent sense!):
beforeCommit -> object A
beforeCommit -> object B
beforeCommit -> context
...DB activity...
afterCommit -> object A
afterCommit -> object B
afterCommit -> context
This is a bit more work in the modeller to keep both JPA and Cayenne
callbacks clear, but the end result might be more understandable,
even if we end up with beforeCommitDelete, beforeCommitInsert,
beforeCommitUpdate.
Ari
--
-->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Making sense of callbacks
On Sep 28, 2009, at 4:08 AM, Lachlan Deck wrote: So from what I can see the only two changes required were 'postInsert' and adjusting the meaning of prePersist I also tend to think that less is better. This discussion thread was a nice brainstorming on the callbacks use patterns. So we've played with a few things and now I am fine if we go a full circle to the minimal change suggested earlier, and don't worry about JPA users, extra delete callbacks, or symmetry between callback types (in many respects there's little symmetry if you look at the object lifecycle - http://cayenne.apache.org/doc/persistent-object-lifecycle.html) . So here is the change I am going to make: 1. Call "prePersist" before commit 2. Introduce "postAdd" instead of current "prePersist". This change is minimal and is not incompatible with other ideas. Objections? Andrus
Re: Passing null values in parameters, part 2 )
Yeah, seems like a JDBC driver issue having hard time guessing the type of the result (which Cayenne takes from ResultSetMetadata). So just to doublecheck, if you do #bind($MyNumericColumn 'int'), it doesn't make a difference? As for the solution if nothing works, Cayenne 3.0 has an ability to set explicit result mapping via API: http://cayenne.apache.org/doc/api/org/apache/cayenne/query/SQLTemplate.html#setResult(org.apache.cayenne.map.SQLResult) Not sure 100% if it solves this problem, but let's check things one step at a time... Andrus On Sep 28, 2009, at 5:58 PM, Evgeny Ryabitskiy wrote: Hello to everyone! After previous fix I can pass null values in parameters to SQLTemplates. It's working and it's cool! Now I have one more issue... : Here is query (very simple.. to focus on this issue, that I can't avoid by changing SQL or add directives like #bind or #result) SELECT isnull(#bind($MyNumericColumn), AnotherNumericColumn) AS MyColumn FROM MyTable If I pass some not null Decimal value it's working properly and returns BigDecimal value. But if I pass null or not pass anything.. it's still working! but return type is java.lang.String .. course null now has special JDBC type for it and JDBC converts my Numeric to String. I have only one idea: pass JDBC type with my null in parameters (like special class "JDBCTypedNull" with constructor and pass there JDBC type or value type and map it to JDBC). Any other suggestions? Best regards, Evgeny Ryabitskiy.
Re: CM Bug?
This could be due to the long standing preferences stability bug. Check ~/.cayenne/prefs/1.2 directory. If you see a bunch of db1.XXX, db2.XXX files, it means the prefs db is in a bad state. In this case my suggestion is to stop the Modeler and rm -rf the entire ~/.cayenne/ prefs/1.2 folder. I hope Olga may have some time to look at Modeler preferences rework for 3.0 to use built-in Java preferences API instead of relying on the embeddable DB's. Andrus On Sep 28, 2009, at 10:28 PM, Michael Gentry wrote: Can anyone else confirm this? It has happened to me twice today so far. I have a local data source defined (in CM preferences). If I change models, the local data source goes away. Permanently. It isn't even there if I open up the original model I had been using where I know I had the data source. Also, the ClassPath setting in CM preferences gets nuked, too. Maybe more.
Re: CM Bug?
On Sep 29, 2009, at 10:23 AM, Adrian A. wrote: Wouldn't simply replacing HSQLDB with H2 (http:// www.h2database.com/) solve the problem with far less effort? Possibly. H2 option had been discussed, but I guess nobody ever tried it. Thanks for the hint. Andrus
Re: Passing null values in parameters, part 2 )
On Sep 28, 2009, at 11:09 PM, Evgeny Ryabitskiy wrote: If I explicitly set JDBC type in bind directive, I get right type (the one that I have set explicitly). Good to know. Set whole result is a solution but also not so flexible. If I have select from 10 columns and want change type of only one column I should pass all 10 types (where 9 is same that returns by default). Agree, this is painful, done for purely implementation reasons and is something we should handle better. I wish to have ability to optionally set result type for several columns from API. I have very simple idea: To have standard Object-wrapper (name like "BindValue" or something like that) that contains reference to Object (or null) and it's JDBC type and precision. After we touch BindDirective to work with this "BindValue", we can anytime pass BindValue and explicitly set JDBC type through API. I like the idea, but maybe we can take this even further, and provide an API substitute for the entire directive, e.g. instead of #bind($bindDirective) we'd have $bindDirective i.e. from the user standpoint, extra #bind(..) wrapper seems redundant. Now wonder if we can extend that to other directives, such as #result? What do you think? Andrus
Re: Passing null values in parameters, part 2 )
On Sep 29, 2009, at 12:43 PM, Evgeny Ryabitskiy wrote: I create CAY-1280 and attached draft patch. Maybe I should export this mail conversion there? Yeah I saw that. I suggest we keep the discussion on the list for now, until we come to some conclusion. Then we can simply add a thread archive URL to the Jira for reference. in theory we can do intelligent analyze of SQL query and parameter to determine if we should do bind or put it in template (like table name) but it's not cool! Yes, this is what I had in mind. E.g. making special parameters to implement "Directive" interface of some sort. Why do you think this is a bad idea? It will work exactly like #bind directive if the parameter is BindDirective, as #result if a parameter is a ResultDirective, etc. It seems to be equally counterintuitive to pass a special wrapper object in a variable inside of #bind, as it is in a standalone variable :-) But in the later case we get a more concise syntax that can help in case of large queries. Andrus
Re: CM Bug?
Some preferences are indeed per project, with the key tied to the absolute filesystem path. Andrus On Sep 29, 2009, at 4:48 PM, Michael Gentry wrote: H2 might be worth trying, but it seems to me that CM resets the preferences when you open or create a new model. I'd have to dig in the code a bit, but it sure felt that way the past few days ... On Tue, Sep 29, 2009 at 3:29 AM, Andrus Adamchik > wrote: On Sep 29, 2009, at 10:23 AM, Adrian A. wrote: Wouldn't simply replacing HSQLDB with H2 (http:// www.h2database.com/) solve the problem with far less effort? Possibly. H2 option had been discussed, but I guess nobody ever tried it. Thanks for the hint. Andrus
Re: Passing null values in parameters, part 2 )
On Sep 29, 2009, at 5:42 PM, Evgeny Ryabitskiy wrote: 1) When we don't have bind in template: SELECT * FROM Table1 where PersonName = $MyParamName 2) When we have #bind in template but wish to overwrite it's parameters (JDBC type and precision) via API. SELECT * FROM Table1 where PersonID = @bind($MyParamName 'NUMERIC' 2) /* pass BindDirective with precision 0 here */ Trying to understand whether the second option is redundant. Do you feel like option #1 won't be sufficient and we need to mix BindDirective with #bind? Maybe you have a good example why this is important? About ResultDirective... it is used for SQL return... so we can pass name, jdbc type and precision (no value) to parameters and use it's as hints while mapping to return values. Yeah, the idea here is to fully emulate #result() directive behavior, so the properties will be the same as the #result() parameters. BTW if we can come up with a sensible implementation of CAY-1282 that you just opened, it will be great. This will require some smart matching of column names obtained from ResultSetMetadata with explicitly mapped columns. Not impossible I guess. P.S. Sorry for so slow answering, GMail page is banned at my work proxy :/ No worries. People here are used to asynchronous communication. Andrus
Re: Adding enums?
On Sep 30, 2009, at 6:13 PM, Michael Gentry wrote: I've got a first cut of this ready to check-in after I create a ticket (which I'll have to do at home). Great. For now, I'm using SortOrder, but I'm sure that can change (be refactored) before 3.0 goes final if a better name is desired. That has to be "before 3.0 goes Beta", as our beta promise is no API changes, unless absolutely required to fix a bug. Andrus
Re: Passing null values in parameters, part 2 )
On Sep 30, 2009, at 6:21 PM, Evgeny Ryabitskiy wrote: P.S. Patch was for CAY-1282 ready in the morning (hours ago) but... I couldn't login to Apache JIRA : I can confirm that the problem was on Apache side. Andrus
Fwd: SvnPubSub websites -- need more volunteers
FYI: I think this is something we can take advantage of. Begin forwarded message: From: Paul Querna Date: October 1, 2009 9:46:17 AM GMT+03:00 To: infrastructure-...@apache.org Subject: SvnPubSub websites -- need more volunteers Reply-To: infrastructure-...@apache.org Hi, apr.apache.org is now managed by SvnPubSub. I think we are ready to add more. Any volunteer TLPs? Once its done, any commit to your SVN repo for your site will be automatically propagated to the live servers within seconds. Things i need to know: - Path to Website Checkout - If applicable, do you need a dev/dist directory - Do you want a $tlp.staging.apache.org (Just maps to another SVN url, like $tlp/site/branche/staging) Notes to self current process: - Add new paths to /etc/svnwcsub.conf - Checkout svn paths to /x1/tmp - mv /x1/www/$tlp old-site && mv /x1/tmp/$tlp /x1/www/$tlp - chown -R svnwc /x1/www/$tlp - /etc/init.d/svnwcsub restart
Re: [jira] Updated: (CAY-1284) Update Cayenne Modeler to use the AWT file dialog on OS X.
Hi Michael, Update CM to conditionally check which OS and display the appropriate dialog for OS X. I mentioned that before in the discussion about OS X menus customizations, and let me bring it up again. If possible let's avoid OS checking in the core Modeler code, and implement any OS-specific extensions as overrides in the corresponding OS specific modules, in this case "org.apache.cayenne:cayenne-modeler-mac-ext". Let's keep our code clean. Andrus On Oct 1, 2009, at 3:05 PM, Michael Gentry (JIRA) wrote: [ https://issues.apache.org/jira/browse/CAY-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Gentry updated CAY-1284: Assignee: (was: Michael Gentry) Description: On OS X, the AWT file dialog is mapped to the standard system dialog by Apple. The Swing file dialog is a much less usable (and foreign) version. Update CM to conditionally check which OS and display the appropriate dialog for OS X. was: The Ordering class currently takes booleans to indicate ascending/ descending and case sensitive/insensitive. When reading the code, it is impossible to know what "true" and "false" actually mean unless you are familiar with the API. Update the class to use descriptive enums instead of boolean flags. Environment: OS X (was: All.) Summary: Update Cayenne Modeler to use the AWT file dialog on OS X. (was: Update Ordering to take enums instead of boolean flags.) Update Cayenne Modeler to use the AWT file dialog on OS X. -- Key: CAY-1284 URL: https://issues.apache.org/jira/browse/CAY-1284 Project: Cayenne Issue Type: Improvement Components: CayenneModeler GUI Affects Versions: 3.0M6 Environment: OS X Reporter: Michael Gentry Priority: Minor Fix For: Short term future On OS X, the AWT file dialog is mapped to the standard system dialog by Apple. The Swing file dialog is a much less usable (and foreign) version. Update CM to conditionally check which OS and display the appropriate dialog for OS X. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SvnPubSub websites -- need more volunteers
Ah right. We don't check in docs to SVN like we used to before Confluence. Then it is of no use to us. Sorry for the noise. Andrus On Oct 2, 2009, at 2:37 AM, Aristedes Maniatis wrote: On 1/10/09 5:07 PM, Andrus Adamchik wrote: FYI: I think this is something we can take advantage of. I'm a bit confused about how we would use it. Here's what I know of in our publishing process: 1. Confluence -> autoexport -> disk -> rsync -> web server (/) 2. Javadoc maven build (p.a.o/~amaniatis) -> disk -> rsync -> webs server (/doc/api) 3. maven script run just before release -> docs commit to svn Are you thinking about step 3 for this tool? Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: [jira] Commented: (CAY-1287) SQLTemplate for not-mapping (DataRow) queries
I am taking this to dev, as Jira is a poor medium for discussion.
On Oct 2, 2009, at 2:33 PM, Evgeny Ryabitskiy (JIRA) wrote:
But it's also very confusing to developer course he don't know which
Map to Use and User Guide have nothing about it.
How come you don't know which DataMap to use, but know which DataNode
to use? I would think that if you know the later, you'd definitely
know the former. Unless you have projects that are just DataNodes
without any DataMaps?
We should write about it there!
I have simple solution for it.. At least it's not confusing to new
developer :
// new constructor using only DataNode
public SQLTemplate(DataNode dataNode, String defaultTemplate) {
//use any DomainMap course there is no metter...
this(dataNode.getDomainMaps.iterator().next(), defaultTemplate);
}
I explained why this is not going to work in Jira. Let me reiterate.
Referencing DataNode in the user code is prohibited by design. Queries
are designed to be run via an ObjectContext that can map to multiple
nodes, and can be executed from remote layers with no access to
DataNode. So Cayenne general purpose queries must not have API
dependency on the DataNode. There's a level of indirection that I
think is not that hard for the end user to use.
I can agree about better documentation, but now that I described how
it works, does it make sense? It is easier to create missing
documentation instead of changing the main framework assumptions.
Andrus
Re: [jira] Commented: (CAY-1287) SQLTemplate for not-mapping (DataRow) queries
On Oct 2, 2009, at 3:28 PM, Рябицкий Евгений wrote: DataMap doesn't belong to DataNode? It does not "belong", but is rather "linked to" a single DataNode. Still think that we can improve Cayenne query engine ;) I don't disagree with such statement in general. There's lots of legacy API that we should clean up. I explained why this specific suggestion won't be a good idea though. P.S. Don't want to be annoying... but still looking forward to you answers to my other issues... :) Sure. Could you please send those as an email to this or the user list. I may not be able to answer right away (busy with work), but others may have answers faster. Having it on the list instead of Jira provides a better chance it gets noticed. Cheers, Andrus
Re: Passing null values in parameters, part 2 )
On Sep 30, 2009, at 6:21 PM, Evgeny Ryabitskiy wrote: Without this option I have to variants: 1) Change #bind($) to $... everywhere and every time pass our special mapping objects to parameters (I will die/be killed by colleges early...). So this argument is based on the fact that people are using #bind() already. With the new approach they'd just need to optionally change the Java parameter code, and the alternative would be to change both template code as well as Java code. I am still not convinced that the second option is any harder or more confusing. To me the first option is confusing actually - when I pass a binding object, and the directive already has some properties, it is not immediately obvious which set of properties will take effect. 2) Use not general style in SQLTemplate, somewhere with #bind, somewhere not... Firstly it's confusing... Second Is potential errors when I forget where I should pass simple Object and where is special bind object. Our current approach with Velocity templates is by definition error- prone, as there's no parameter type checking anywhere. IMO adding the new option won't make it better or worse in this respect. Just like you in this case, I always look at the new API from the point of view of whether it is internally consistent and easy to explain to the end users. In this case I think having "$xyzSpecialObject" as an alternative to an "#XYZ" directive seems like a straightforward symmetrical replacement. At the same time using "#XYZ($xyzSpecialObject $p1 $p2 $p3)" as a way to override some parameters appears indeterministic to an uninitiated person. Cheers, Andrus
Re: Making sense of callbacks
I finished this per CAY-1281. Project upgrade is performed on opening it in the Modeler, so migration for the existing callback users is straightforward. Haven't checked whether that works for ROP. I would appreciate if somebody could help me with that. Andrus On Sep 28, 2009, at 9:53 AM, Andrus Adamchik wrote: On Sep 28, 2009, at 4:08 AM, Lachlan Deck wrote: So from what I can see the only two changes required were 'postInsert' and adjusting the meaning of prePersist I also tend to think that less is better. This discussion thread was a nice brainstorming on the callbacks use patterns. So we've played with a few things and now I am fine if we go a full circle to the minimal change suggested earlier, and don't worry about JPA users, extra delete callbacks, or symmetry between callback types (in many respects there's little symmetry if you look at the object lifecycle - http://cayenne.apache.org/doc/persistent-object-lifecycle.html). So here is the change I am going to make: 1. Call "prePersist" before commit 2. Introduce "postAdd" instead of current "prePersist". This change is minimal and is not incompatible with other ideas. Objections? Andrus
Re: Passing null values in parameters, part 2 )
Hi Evgeny, Thanks for explaining it in detail. I think now I am clear on the proposed scope of the feature and the motivation behind it. While this didn't change my initial assessment of the redundancy of the #bind($bind) option, still I see no harm in the extra functionality of the #bind directive, especially considering that you will be submitting a patch for it (so I agree to disagree :-)). So let's go for it. I suggest that we don't limit it to just #bind($bind), but support it for all flavors of the bind directive. Also like CAY-1282, this is something that will go to 3.0 only. As we've contemplated doing a 3.0 beta release soon, keep us posted on the progress, as beta would also mean a complete feature freeze for 3.0. And on the upside, it may mean that your company can start using 3.0 as an API-stable release in your work. Thanks, Andrus On Oct 4, 2009, at 6:56 PM, Evgeny Ryabitskiy wrote: So this argument is based on the fact that people are using #bind() already. With the new approach they'd just need to optionally change the Java parameter code, and the alternative would be to change both template code as well as Java code. Yes! My argument is based on that people are using #bind already in our NamedQueries in our xml files... And no one want to change something that was written once and still working... Maybe one thing that I forgot to tell... Any our NamedQuery can be used in lot's of places... Yeah... huge bank systems And I can't change it one place from Java and one from queries. I should find every use of this query in Java and change it to use BindObject it's too painful! So that is why Queries should be independent from Java-code, that is why I need queries in one stile and can't just delete somewhere #bind and somewhere not. So again I have only 2 options.. no compromises: 1)everywhere #bind; 2) nowhere #bind and special BindObject everywhere in Java Code. I am not going to choose second option... :) So without overwriting this API tool is useless for us. I know Cayenne is not just for me and my project (even my project is great!)... but I also don't think that my case is so unic. I'm not along who wish to have queries in one style! I am still not convinced that the second option is any harder or more confusing. To me the first option is confusing actually - when I pass a binding object, and the directive already has some properties, it is not immediately obvious which set of properties will take effect. For me and my team it's absolutely not confusing. Look.. we have some NamedQuery.. it's used in several places. So in one place we are passing null and I wish to pass type with this null to do some hint for JDBC driver to use right type mapping. So I am overwriting default mapping from #bind($..) by BindValue object and... few lines later.. I am expecting right type mapping in result. Don't think it should be confusing to developer. Just like you in this case, I always look at the new API from the point of view of whether it is internally consistent and easy to explain to the end users. In this case I think having "$xyzSpecialObject" as an alternative to an "#XYZ" directive seems like a straightforward symmetrical replacement. At the same time using "#XYZ($xyzSpecialObject $p1 $p2 $p3)" as a way to override some parameters appears indeterministic to an uninitiated person. When I was talking about overwriting I had in mind just #bind($...) directive, without explicit set of JDBC type. The point of "my" overwriting is to control implicit binding (where is no JDBC type parameter in SQLTemplate). So maybe in case of #bind($param 'VARCHAR') it can be confusing to overwrite type from API. So... I can suggest one more compromise to overwrite #bind($..) only where is no explicit JDBC type. Less confusing... more safe from developer point Evgeny Ryabitskiy.
Beta 1 ?
I suggest that we consider wrapping up the current release cycle, release 3.0B1 and go into a runtime new feature freeze associated with the Beta part of the cycle. We had a burst of new development activity in the past couple of weeks, which is awesome, and I don't want to get in its way with the feature freeze, but let's see what issues we have left, and see which ones are actually being worked on: http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310903&created%3Aprevious=-3w&status=1&status=3&sorter/field=created&sorter/order=DESC CAY-1282: I think this is close to completion by Evgeny, and is a very nice addition that I'd love to see in Cayenne. CAY-1287: IMO the only thing that is needed there is docs improvement, so not a subject to code freeze. CAY-1283: In progress (or is it finished?) CAY-1280: An idea of overrides for SQLTemplates. I think Evgeny is also planning to work on it in the near term. CAY-1284, CAY-1288: Not sure if Michael plans an immediate action on those? So unless Michael and Evgeny ask for more time to finish CAY-1280, CAY-1284, CAY-1288, I suggest that we have a preliminary B1 tag date set to 2 weeks from now - October 22. By then we'll see how we are doing with the remaining tasks, and make a decision. Finally, I think Beta should go into a stable branch, and then trunk can be immediately open for 3.1 commits without affecting the Beta. But then of course we need to keep trunk in sync with Beta bug fixes and Modeler changes, which IMO not a big deal, just something to keep in mind. Andrus
Re: Beta 1 ?
On Oct 8, 2009, at 2:38 PM, Andrey Razumovsky wrote: It shows CAY-1239 I am ready to sacrifice this one. CAY-1276 on the way to Beta1. And, we'll have to Yeah, need to finish that. I will chat Olga - hopefully we can do it. finish CAY-1191 which is Undo/Redo to be able to release 3.0B1. Traditionally we don't freeze the Modeler in Beta, as officially Modeler code is a black box to the users. It is frozen for stability reasons at the next stage - RC (release candidate), so this one won't get in the way. CAY-1260 is another Modeler issue that I just reclassified as 3.0, since it is almost done, but may not be finished by B1. Andrus
Re: svn commit: r822698 - /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/reflect/LifecycleCallbackRegistry.java
Nah, just overlooked it during refactoring I guess. Good catch. Thanks
for fixing it.
Andrus
On Oct 8, 2009, at 4:45 PM, Andrey Razumovsky wrote:
Hi Andrus,
Was removing prePersist from Lifecycle listener done intentionally?
2009/10/7
Author: andrey
Date: Wed Oct 7 12:42:39 2009
New Revision: 822698
URL: http://svn.apache.org/viewvc?rev=822698&view=rev
Log:
fixing problem with default listeners in new callback model
Modified:
cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/
java/org/apache/cayenne/reflect/LifecycleCallbackRegistry.java
Modified:
cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/
java/org/apache/cayenne/reflect/LifecycleCallbackRegistry.java
URL:
http://svn.apache.org/viewvc/cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/reflect/LifecycleCallbackRegistry.java?rev=822698&r1=822697&r2=822698&view=diff
=
=
=
=
=
=
=
=
=
=
---
cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/
java/org/apache/cayenne/reflect/LifecycleCallbackRegistry.java
(original)
+++
cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/
java/org/apache/cayenne/reflect/LifecycleCallbackRegistry.java
Wed Oct 7 12:42:39 2009
@@ -75,6 +75,7 @@
*/
public void addDefaultListener(LifecycleListener listener) {
addDefaultListener(LifecycleEvent.POST_ADD, listener,
"postAdd");
+addDefaultListener(LifecycleEvent.PRE_PERSIST, listener,
"prePersist");
addDefaultListener(LifecycleEvent.POST_PERSIST, listener,
"postPersist");
addDefaultListener(LifecycleEvent.PRE_REMOVE, listener,
"preRemove");
addDefaultListener(LifecycleEvent.POST_REMOVE, listener,
"postRemove");
--
Andrey
Re: Beta 1 ?
On Oct 8, 2009, at 4:51 PM, Aristedes Maniatis wrote: Can I suggest that all tasks be moved out of 3.0 and into 3.0 beta 1 or into 3.1 as appropriate. +1 Ideally 3.0 is reserved for tasks which are bugs found in beta 1. Also unfinished Modeler tasks that are not bugs. Andrus
Re: Cayenne-trunk - Build # 477 - Failure
This is something related to the latest Andrey's commit: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /export/home/hudson/hudson/jobs/Cayenne-trunk/workspace/trunk/ framework/cayenne-jdk1.5-unpublished/src/test/java/org/apache/cayenne/ CayenneContextWithDataContextTest.java:[197,28] org.apache.cayenne.CayenneContextWithDataContextTest$1> is not abstract and does not override abstract method prePersist(java.lang.Object) in org.apache.cayenne.LifecycleListener /export/home/hudson/hudson/jobs/Cayenne-trunk/workspace/trunk/ framework/cayenne-jdk1.5-unpublished/src/test/java/org/apache/cayenne/ CayenneContextWithDataContextTest.java:[298,28] org.apache.cayenne.CayenneContextWithDataContextTest$2> is not abstract and does not override abstract method prePersist(java.lang.Object) in org.apache.cayenne.LifecycleListener /export/home/hudson/hudson/jobs/Cayenne-trunk/workspace/trunk/ framework/cayenne-jdk1.5-unpublished/src/test/java/org/apache/cayenne/ CayenneContextWithDataContextTest.java:[354,28] org.apache.cayenne.CayenneContextWithDataContextTest$3> is not abstract and does not override abstract method prePersist(java.lang.Object) in org.apache.cayenne.LifecycleListener On Oct 8, 2009, at 5:29 PM, Apache Hudson Server wrote: The Apache Hudson build system has built Cayenne-trunk (build #477) Status: Failure Check console output at http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/477/ to view the results.
Re: ObjectContext Questions
On Oct 8, 2009, at 7:09 PM, Michael Gentry wrote: Does it make sense to use here? After all, deleteObject() doesn't use it: void deleteObject(Object object) throws DeleteDenyException; Good question... Using Object instead of Persistent was a move towards POJO persistent objects, which only happened half way in 3.0... I am ok if we do not parameterize the collection here. Also, I noticed this added to 3.0: void prepareForAccess(Persistent object, String property, boolean lazyFaulting); Seems like that boolean would be another good place to have an enum instead? Actually no. To me it looks like a case when boolean is just that - a boolean. Andrus
Re: Beta 1 ?
Milestone releases had lots of unfinished *new* functionality, as we only guaranteed that the *existing* functionality is working. Same thing here, only the scope of unfinished functionality is limited to the Modeler. We define what Milestone vs. Beta vs. RC means, and historically the meaning has been what I just mentioned. Don't see any problem with this approach going forward, as long as we explain the rules to the users. Also the downside of NOT declaring Beta until we reach some ideal state throughout the board, is that the feature creep will continue, and it will be hard to stop it. Andrus On Oct 8, 2009, at 9:39 PM, Andrey Razumovsky wrote: Traditionally we don't freeze the Modeler in Beta, as officially Modeler code is a black box to the users. It is frozen for stability reasons at the next stage - RC (release candidate), so this one won't get in the way. Yes but release is sort of product, so I'd prefer it would not have half-finished functionality. There's not that much to finish anyways -- Andrey
Re: Test results
On Oct 9, 2009, at 2:33 PM, Ольга Ткачева wrote: I will try to find reasons this. Hi Olga, Yeah, looks like a few things have changed since M6. Thanks for doing all this regression testing and working on fixing it. Hopefully this is just a few problems that affected the variety of test conditions. Cheers, Andrus
Re: ObjectContext Questions
On Oct 8, 2009, at 10:40 PM, Michael Gentry wrote: It just seems like it is caught in 3 different lands: pre-generics, generics, and POJO. That's one of my biggest headaches. You'd be experimenting with new things, going through trial and error cycles, learning, gathering feedback, and then somewhere along that way your unfinished designs become public API and you can't change it anymore. This is why JPA was so attractive at first - it has a very thin layer of public API, and 85% of the framework is private. And this is why I brought up dependency injection (and implicitly, coding to interfaces) as a prospective future direction. Hmmm... sometimes I feel like attacking that the Tapestry (or Log4J/ SLF4J) way - rewriting things from scratch to have a fresh and fully consistent framework. But then I realize that I won't be able to spend the next 2-3 years of my life to create something that is already available and works, and lose the entire community in the process. Alas, we are stuck in the imperfect world, and will have to make incremental changes :-/ Andrus
Re: ObjectContext Questions
Yeah, I wasn't making an excuse, just sharing my perception of reality :-) Andrus On Oct 9, 2009, at 4:23 PM, Michael Gentry wrote: I'm quite OK with incremental changes. I was just pointing out that when you look at that one class (which is pretty core) it is a bit of a head-scratcher. No worries, though. And no one expects you to be Howard. One of Cayenne's strengths is the stability it has had. Thanks, mrg On Fri, Oct 9, 2009 at 7:42 AM, Andrus Adamchik > wrote: On Oct 8, 2009, at 10:40 PM, Michael Gentry wrote: It just seems like it is caught in 3 different lands: pre-generics, generics, and POJO. That's one of my biggest headaches. You'd be experimenting with new things, going through trial and error cycles, learning, gathering feedback, and then somewhere along that way your unfinished designs become public API and you can't change it anymore. This is why JPA was so attractive at first - it has a very thin layer of public API, and 85% of the framework is private. And this is why I brought up dependency injection (and implicitly, coding to interfaces) as a prospective future direction. Hmmm... sometimes I feel like attacking that the Tapestry (or Log4J/ SLF4J) way - rewriting things from scratch to have a fresh and fully consistent framework. But then I realize that I won't be able to spend the next 2-3 years of my life to create something that is already available and works, and lose the entire community in the process. Alas, we are stuck in the imperfect world, and will have to make incremental changes :-/ Andrus
Re: [jira] Resolved: (CAY-1288) Add deleteObjects() to ObjectContext
On Oct 9, 2009, at 10:13 PM, Michael Gentry (JIRA) wrote: Fix Version/s: (was: 3.0) 3.0M6 I think this should be 3.0-beta1.
Re: [jira] Resolved: (CAY-1288) Add deleteObjects() to ObjectContext
Yes. On Oct 9, 2009, at 10:20 PM, Michael Gentry wrote: So it should be the release targeted and not the code baseline it was fixed from? On Fri, Oct 9, 2009 at 3:16 PM, Andrus Adamchik > wrote: On Oct 9, 2009, at 10:13 PM, Michael Gentry (JIRA) wrote: Fix Version/s: (was: 3.0) 3.0M6 I think this should be 3.0-beta1.
Re: svn commit: r824078 - /cayenne/main/trunk/pom.xml
Wonder if that's such a good idea?
The last time we had dependencies from snapshot repository on
people.apache.org, we had a major problem when it got wiped out
without warning one day. Maybe worth checking with either infra, or
the maven dev list whether they promise any kind of stability on
repository.apache.org, and what is their snapshot pruning policy.
I dread the return of the days of broken Maven builds from the not so
distant past.
Andrus
On Oct 11, 2009, at 4:59 PM, and...@apache.org wrote:
Author: andrey
Date: Sun Oct 11 13:59:36 2009
New Revision: 824078
URL: http://svn.apache.org/viewvc?rev=824078&view=rev
Log:
changing surefire version
Modified:
cayenne/main/trunk/pom.xml
Modified: cayenne/main/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/cayenne/main/trunk/pom.xml?rev=824078&r1=824077&r2=824078&view=diff
=
=
=
=
=
=
=
=
==
--- cayenne/main/trunk/pom.xml (original)
+++ cayenne/main/trunk/pom.xml Sun Oct 11 13:59:36 2009
@@ -513,7 +513,7 @@
-
+
apache-snapshots
@@ -546,6 +546,20 @@
true
+
+ plugin-snapshots
+ Apache Snapshots Repository
+ http://repository.apache.org/snapshots/
+ default
+
+ true
+ weekly
+ ignore
+
+
+ false
+
+
@@ -553,6 +567,7 @@
maven-surefire-plugin
+ 2.5-SNAPSHOT
-Dcayenne.test.connection=${cayenne.test.connection} -
Djava.net.preferIPv4Stack=true
Re: [jira] Updated: (CAY-1282) Use #result as optional directive for only few columns (not all)
Hi Evgeny,
As always, thanks for the patch. A few comments:
1. A refactoring suggestion: move the new static methods introduced in
ColumnDescriptor to non-static methods of RowDescriptorBuilder.
2. In 3.0 unit test classes are using *Test suffix instead of *Tst,
and also we no longer put @author tags in the code.
Both items above are minor, and I can change them myself. Here is one
potentially bigger issue with the patch though:
3. The patch merges 2 strategies for creation of columns descriptor
into one, that requires access to ResultSetMetadata. I am not sure
that ResultSet.getMetaData() is a trivial operation for all JDBC
drivers that we support. I suspect there may be overhead accessing
this data at least on some DBs. While we can verify this theory, I am
wondering if we should, as in most cases we control the query syntax
and don't need to consult ResultSetMetadata at all.
So maybe preserve the flow in RowDescriptorBuilder, and use your
strategy merging explicit and implicit column descriptors *only* when
an optional metadata object is initialized?
Andrus
On Oct 9, 2009, at 2:08 PM, Evgeny Ryabitskiy (JIRA) wrote:
[ https://issues.apache.org/jira/browse/CAY-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Ryabitskiy updated CAY-1282:
---
Attachment: CAY-1282-3.patch
Done!
Use #result as optional directive for only few columns (not all)
Key: CAY-1282
URL: https://issues.apache.org/jira/browse/CAY-1282
Project: Cayenne
Issue Type: Improvement
Components: Cayenne Core Library
Affects Versions: 1.2.5, 2.0.5, 3.0
Reporter: Evgeny Ryabitskiy
Assignee: Andrus Adamchik
Fix For: 3.0 beta 1
Attachments: CAY-1282-3.patch, CAY-1282-3.patch,
CAY-1282-3.patch, CAY-1282-3.patch, CAY-1282-3.patch, CAY-1282.patch
Here is few queries to show the problem:
SELECT ARTIST_ID, ARTIST_NAME FROM ARTIST
- working properly
SELECT #result('ARTIST_ID' 'java.lang.Integer'),
#result('ARTIST_NAME' 'java.lang.String') FROM ARTIST
- also working properly
SELECT ARTIST_ID, #result('ARTIST_NAME' 'java.lang.String') FROM
ARTIST
- first column is returned as null!!! Not nice...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r824078 - /cayenne/main/trunk/pom.xml
On Oct 11, 2009, at 5:14 PM, Andrey Razumovsky wrote: Well, as already mentioned, we need surefire-2.5, which is in that repo. It's not much help if that snapshot gets deleted from there tomorrow without telling us, which is a real possibility, as it happened before. I'm afraid I don't know whom to ask about stability of the repo. You may start with infrastruct...@a.o Andrus
Re: svn commit: r824078 - /cayenne/main/trunk/pom.xml
BTW, as a backup plan I can import all needed snapshots to http://objectstyle.org/maven2/ which is already referenced from Cayenne POMs. Just give me a list of artifacts. Andrus On Oct 11, 2009, at 5:24 PM, Andrus Adamchik wrote: On Oct 11, 2009, at 5:14 PM, Andrey Razumovsky wrote: Well, as already mentioned, we need surefire-2.5, which is in that repo. It's not much help if that snapshot gets deleted from there tomorrow without telling us, which is a real possibility, as it happened before. I'm afraid I don't know whom to ask about stability of the repo. You may start with infrastruct...@a.o Andrus
Re: [jira] Updated: (CAY-1282) Use #result as optional directive for only few columns (not all)
On Oct 12, 2009, at 12:38 AM, Evgeny Ryabitskiy wrote: If we talking about re-factor... I really wish to rewrite there everything to use some Collection.. like ArrayList... or maybe even HashSet. In that case I can use just really fast hashed contains() method instead going through all array of columns. So.. collections is more safe, is much more flexible in code. And in some cases even faster. I think usage of simple arrays is deprecated since Java 1.5 But it's huge patch.. to change every ColumnDescriptor[] on some Collection. So.. what do you think? It doesn't matter how this represented *inside* the builder class, as builder is used only once per query. On the other hand, coming out of the builder it must be optimized, as access to the column descriptors array is performed N*M times during each result set processing, where N is the width of the result set, and M is its length. I.e. it can be a very large number (up to tens or hundreds of millions calls). Every small optimization matters here. I think usage of simple arrays is deprecated since Java 1.5 This is most certainly NOT true. 3. The patch merges 2 strategies for creation of columns descriptor into one, that requires access to ResultSetMetadata. I am not sure that ResultSet.getMetaData() is a trivial operation for all JDBC drivers that we support. I suspect there may be overhead accessing this data at least on some DBs. While we can verify this theory. Yeah.. we should verify it, but I think ResultSetMetadata is formed when result is returned.. anyway.. It's just a getter... do you think ResultSetMetadata is "lazy" initialized? This is something I don't know. We need to check about a dozen of drivers from different vendors that we support to verify that. This is just a getter in the interface. Implementors could've made it anything. So maybe preserve the flow in RowDescriptorBuilder, and use your strategy merging explicit and implicit column descriptors *only* when an optional metadata object is initialized? The problem that if we don't set ResultSetMetadata like in current (trunk) version, without ResultSetMetadata we don't know all columns.. Not true. We don't know all the columns for SQLTemplate queries. For all other types of queries we DO know all the columns, as Cayenne generates SQL from scratch for those queries. I think this one place is where we have the biggest mismatch in our views of the implementation. Andrus
Re: [jira] Updated: (CAY-1282) Use #result as optional directive for only few columns (not all)
On Oct 12, 2009, at 10:30 AM, Andrus Adamchik wrote: Yeah.. we should verify it, but I think ResultSetMetadata is formed when result is returned.. anyway.. It's just a getter... do you think ResultSetMetadata is "lazy" initialized? This is something I don't know. We need to check about a dozen of drivers from different vendors that we support to verify that. This is just a getter in the interface. Implementors could've made it anything. Another thing to check here is actually reading column data from returned ResultSetMetadata, as lazy resolving of it can be postponed a step further. Andrus
Re: [jira] Updated: (CAY-1282) Use #result as optional directive for only few columns (not all)
Excellent. Looks like we are on the same page now.
Re: HashSet (HashMap?) vs. []. The map is definitely performing better
when you are looking up a value by its key. This may be the case when
we are assembling column descriptors inside the builder. This
operation is done 1 time (ok maybe it is done N times, where N is the
number of columns).
However processing the ResultSet is a different story. There's no
lookup by key. For each ResultSet row we need to apply ALL column
descriptors one by one to get the values out. So with a HashSet/
HashMap we'd have this:
Iterator it = map.values().iterator();
while(it.hasNext()) {
ColumnDescriptor column = it.next();
}
With a ColumnDescriptor[] we have this:
for(int i = 0; i < length; i++) {
column = columns[i];
}
Both loops are done M times, where M is the number of rows in the
ResultSet. In the worst case scenario, M is much larger than N. In the
first case, we call three extra methods (iterator, hasNext, next) and
create at least one extra object (Iterator). So the secon case is
marginally faster. Now if you multiply that nanosecond or whatever
difference by a few millions, it can become more significant.
So essentially when talking about this refactoring we need to separate
the first step of preparing the columns, and the second step of using
them.
Andrus
On Oct 12, 2009, at 12:38 PM, Evgeny Ryabitskiy wrote:
It doesn't matter how this represented *inside* the builder class, as
builder is used only once per query. On the other hand, coming out
of the
builder it must be optimized, as access to the column descriptors
array is
performed N*M times during each result set processing, where N is
the width
of the result set, and M is its length. I.e. it can be a very large
number
(up to tens or hundreds of millions calls). Every small
optimization matters
here.
So.. I was talking exactly about optimization... HashedSet array can
be faster cause we perform several scans over whole array of
ColumnDescriptors. And safety cause we don't get duplicates for
Columns. And.. I didn't get you position about this idea
This is something I don't know. We need to check about a dozen of
drivers
from different vendors that we support to verify that. This is just
a getter
in the interface. Implementors could've made it anything.
I have looked through JTDS drivers (not a dozen but a least one).
ResultSet has all information about columns (just private final
ColInfo[] columns).
When getMetaData performed - constructs new Object that has reference
to array of columns from ResultSet .
Looks like there is no problem with JTDS.
The problem that if we don't set ResultSetMetadata like in current
(trunk) version, without ResultSetMetadata we don't know all
columns..
Not true. We don't know all the columns for SQLTemplate queries.
For all
other types of queries we DO know all the columns, as Cayenne
generates SQL
from scratch for those queries. I think this one place is where we
have the
biggest mismatch in our views of the implementation.
ah... now I see. You are right that was a mismatch in our views. I
will work on it in the evening.
Another thing to check here is actually reading column data from
returned ResultSetMetadata, as lazy
resolving of it can be postponed a step further.
Again in JTDS it's just a array of ColInfo (like our
ColumnDescriptor), it's passed to RowSet through constructor from
protocol implementation.
Evgeny Ryabitskiy.
Re: [jira] Updated: (CAY-1282) Use #result as optional directive for only few columns (not all)
Hi Evgeny, First of all, thanks for your work on this patch. This closes arguably the biggest usability hole in SQLTemplate. I Just committed the patch, with the only change being removal of the public case transform method from ColumnDescriptor and inlining it into the builder class. Also added this comment to the builder code: // TODO: andrus, 10/14/2009 - 'equalsIgnoreCase' check can result in // subtle bugs in DBs with case-sensitive column names (or when quotes are // used to force case sensitivity). Alternatively using 'equals' may miss // columns in case-insensitive situations. In a couple of days we'd see if this problem pops up during the tests with DBs other than HSQLDB. Hopefully not. 2. Also with this and CAY-1293 patch by Olga, we are very close to freezing the code for the 3.0 Beta. Are you planning to work on a patch for CAY-1280 in the nearest future, or are you ok to postpone it till 3.1 release (In practical terms, 3.1 choice means that if you'd like to use this in your work, you'd have to start using trunk builds with your apps, or maintain the internal patched version of 3.0). Cheers, Andrus
Re: Test results
Thanks Olga. Aside from my comments on CAY-1293 Jira, looks like we are in a good shape. Although we'll need at least one more cross-DB regression to check CAY-1282 (and possibly yet uncommitted CAY-1280) effects. Cheers, Andrus On Oct 15, 2009, at 7:02 PM, Ольга Ткачева wrote: I added patch in *CAY-1293 <https://issues.apache.org/jira/browse/CAY-1293 >*. It fix some tests. As a result, on databases postgres, oracle, h2, sybase tests are successful. I have not fix 2 failed tests in sqlserver and db2. And i didn't look sqlite. In sqlserver: Failed tests: testFetchLimitWithOffset(org.apache.cayenne.query.SelectQueryTest) In db2: Failed tests: test(org.apache.cayenne.merge.SetPrimaryKeyToDbTest) In mysql were 2 tests with errors. They were before, in last release. Tests in error: test1MBClob(org.apache.cayenne.access.DataContextClobTest) test1MBBlob(org.apache.cayenne.access.DataContextBlobTest) In derby were 2 tests with errors. They also were before. (derby don't support DISTINCT in Subquerys) Tests in error: testDifferentEntity (org.apache.cayenne.access.DataContextEJBQLSubqueryTest) testExists(org.apache.cayenne.access.DataContextEJBQLSubqueryTest) 9 октября 2009 г. 14:38 пользователь Andrus Adamchik написал: On Oct 9, 2009, at 2:33 PM, Ольга Ткачева wrote: I will try to find reasons this. Hi Olga, Yeah, looks like a few things have changed since M6. Thanks for doing all this regression testing and working on fixing it. Hopefully this is just a few problems that affected the variety of test conditions. Cheers, Andrus -- Olga
Re: [jira] Updated: (CAY-1282) Use #result as optional directive for only few columns (not all)
On Oct 16, 2009, at 12:44 PM, Evgeny Ryabitskiy wrote: Yeah.. good idea. We should think about how we can get information about "case-sensibility" of DB. If you can give me some hint about it, I can just parametrize this comparing for 2 columns. Auto-guessing column capitalization has been challenging for us so far. Till now we sort of pushed that on the users (e.g. see a second patch for CAY-1293). Something to check is whether ResultSetMetaData.html.isCaseSensitive(..) works reliably across the board. Factors that can affect that (and that need to be tested) are: * the type of the DB * the way tables are created in that DB and other DB-specific configuration parameters that may affect case sensitivity * whether Cayenne is configured to quote column names or not (this can be done in the Modeler since 3.0) 2. Also with this and CAY-1293 patch by Olga, we are very close to freezing the code for the 3.0 Beta. Are you planning to work on a patch for CAY-1280 in the nearest future, or are you ok to postpone it till 3.1 release (In practical terms, 3.1 choice means that if you'd like to use this in your work, you'd have to start using trunk builds with your apps, or maintain the internal patched version of 3.0). Yes, I'm going to work on it on weekends.When we are going to freeze 3.0 Beta? Cool. A decision when to create a beta release tag will be a result of an informal consensus among Cayenne developers. IMO, the only thing left to finish is CAY-1280, so I am asking whether this is going to happen soon. Andrus
Re: [jira] Updated: (CAY-1282) Use #result as optional directive for only few columns (not all)
On Oct 16, 2009, at 8:04 PM, Andrey Razumovsky wrote: Actually, as already mentioned, we need to do something around CAY-942 (query generics). This is very critical and desired API change Not sure if we have another more precise Jira (since generics in relationships mentioned in this Jira have already been added). Anyways, if we are talking about query generics, I did some research and prototyping of that in the past. My conclusion is that to do it right it has to be a rather dramatic change in Cayenne, affecting not simply the code, but a number design concepts. Essentially we have too many variables to squeeze into a rather rigid Java generics engine. To start, here is possible query result types: ? extends Persistent ? extends Object (unfinished POJO implementation) CayenneDataObject (as in "generic persistence" [1]) DataRow scalar Object[] (a mix of scalars and any of the above) I don't see how we can easily parameterize that in a meaningful way. So my vote is to postpone this till 3.1 and make it a 3.1 priority to create an appropriate generics based query design, and maybe reduce the number of options. I don't think significantly delaying and radically changing 3.0 (that has been de-facto stable for some time) is a good idea. Andrus [1] http://cayenne.apache.org/doc/generic-persistent-class.html
Re: [jira] Updated: (CAY-1282) Use #result as optional directive for only few columns (not all)
On Oct 16, 2009, at 6:17 PM, Evgeny Ryabitskiy wrote: If I'm the only person who is blocking release then let's delay my CAY-1280 till 3.1 We found some solution to handle our problems without this issue, so we can wait. Great, we'll go ahead with the release then. But it's still very useful thing :) Agreed. Andrus
release countdown
One more task left to do - update the user guide with things that changed from M6 and sync it to SVN. I will hopefully do that over the weekend and then assemble artifacts for a vote. Andrus
Re: release countdown
Thanks for brining it up. I completely forgot about this one. I suggest rescheduling CAY-400 to 3.1, as I suspect it will require a non-trivial time investment by a committer, and very likely will cause more API discussion. Andrus On Oct 22, 2009, at 9:19 AM, Andrey Razumovsky wrote: aren't we going to commit CAY-400? I think it was finished some time ago 2009/10/22 Aristedes Maniatis On 21/10/09 6:32 PM, Andrus Adamchik wrote: One more task left to do - update the user guide with things that changed from M6 and sync it to SVN. I will hopefully do that over the weekend and then assemble artifacts for a vote. Andrus What are we going to do with https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310903&fixfor=12313971 and https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310903&fixfor=12313760 Also is CAY-1260 done? It would be great to move everything in Jira to the right versions so it is clear exactly what is left to do. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A -- Andrey
Re: release countdown
* CAY-1067: changed issue to type to "Bug" (which it is), so we can work on it while in Beta. * CAY-1141: related to inheritance, rescheduled. * CAY-1152: may fix while in Beta, or may reschedule * CAY-1162: closed as "Won't Fix". This was related to inheritance work that got postponed. * CAY-1165: changed fix version to "Unknown". This is really low priority. * CAY-1191: partially done. Per Andrey there are still some problems. Will hopefully fix them while in Beta. * CAY-1239: rescheduled to 3.1 * CAY-1260: Mostly done, but still some rough spots remain. Planning to finish it while in Beta. * CAY-1280: rescheduled to 3.1 per our conversation with Evgeny on this list * CAY-1287: this is a documentation issue Andrus On Oct 22, 2009, at 2:36 AM, Aristedes Maniatis wrote: On 21/10/09 6:32 PM, Andrus Adamchik wrote: One more task left to do - update the user guide with things that changed from M6 and sync it to SVN. I will hopefully do that over the weekend and then assemble artifacts for a vote. Andrus What are we going to do with https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310903&fixfor=12313971 and https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310903&fixfor=12313760 Also is CAY-1260 done? It would be great to move everything in Jira to the right versions so it is clear exactly what is left to do. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: release countdown
So we are down to 5 Jiras in 3.0 list and 0 Jiras in B1 list. Andrus On Oct 22, 2009, at 11:04 AM, Andrus Adamchik wrote: * CAY-1067: changed issue to type to "Bug" (which it is), so we can work on it while in Beta. * CAY-1141: related to inheritance, rescheduled. * CAY-1152: may fix while in Beta, or may reschedule * CAY-1162: closed as "Won't Fix". This was related to inheritance work that got postponed. * CAY-1165: changed fix version to "Unknown". This is really low priority. * CAY-1191: partially done. Per Andrey there are still some problems. Will hopefully fix them while in Beta. * CAY-1239: rescheduled to 3.1 * CAY-1260: Mostly done, but still some rough spots remain. Planning to finish it while in Beta. * CAY-1280: rescheduled to 3.1 per our conversation with Evgeny on this list * CAY-1287: this is a documentation issue Andrus On Oct 22, 2009, at 2:36 AM, Aristedes Maniatis wrote: On 21/10/09 6:32 PM, Andrus Adamchik wrote: One more task left to do - update the user guide with things that changed from M6 and sync it to SVN. I will hopefully do that over the weekend and then assemble artifacts for a vote. Andrus What are we going to do with https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310903&fixfor=12313971 and https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310903&fixfor=12313760 Also is CAY-1260 done? It would be great to move everything in Jira to the right versions so it is clear exactly what is left to do. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Aggregated cayenne.xml from several modules (projects)
I was working on this exact problem, but due to the lack of time and
some other priorities it got postponed till after 3.0. This Jira
contains links to the design that I had in mind:
https://issues.apache.org/jira/browse/CAY-943
For 3.1 I actually have more radical ideas, so it may look different
at the end. Anyways, all the complexity of this task is due to the
need to handle a general case of merging multiple descriptors and
resolve arising conflicts. If you know that your configuration does
not have any such conflicts, it should be reasonably simple to merge
things by hand. Here is a rough example (this is for 3.0, some things
may be different in 2.0):
Configuration myConfig = new Configuration() {
// override all abstract methods to do nothing
}
ClassLoader cl = .. // get a thread class loader
// assuming all Cayenne projects are at the root of the classpath:
Enumeration projectURLs = cl.indResources("cayenne.xml");
while(projectURLs.hasMoreElements()) {
URL baseURL = projectURLs.nextElement();
ResourceLocator resourceLocator = new ResourceLocator() {
// override locator methods as appropriate... e.g.:
public URL getResource(String name) {
if(name.equals("cayenne.xml") {
return baseURL;
}
// assuming there's no conflciting DataMap names
return super.getResource(name);
}
} ;
Configuration scratchConfig = new
DefaultConfiguration("cayenne.xml", resourceLocator);
// move all DataMaps from scratchConfig to myConfig
// move all DataNodes from scratchConfig to myConfig
}
Configuration.initializeSharedConfiguration(myConfig);
Andrus
On Oct 21, 2009, at 7:12 PM, Evgeny Ryabitskiy wrote:
Hello to everyone!
I wonder if our cayenne is able to aggregate it's configuration from
several projects?
Like in my case I have several modules, each has it's configuration
like module1-cayenne.xml
So now root project need to get aggregated configuration from all
modules.
So I'm trying to use DefaultConfiguration for each module.
The problem that after initialization configuration rewrites previous
and become singleton configuration (I need them all!)
Maybe I do something wrong or there no such feature?
Evgeny Ryabitskiy.
Re: release countdown
Exactly. This is why I am suggesting to reschedule all things that have a potential of delaying 3.0. A final release till the end of the year will depend on how many bug reports we get. It is definitely doable with the current task queue, but we don't know what else will show up during Beta. Assuming with the best case scenario, I feel like we still need to have at least 2 releases before the final - B1 and RC1. Andrus On Oct 22, 2009, at 12:09 PM, Andrey Razumovsky wrote: I suggest we release final 3.0 until the end of the year. It was a long time since last official release, after all 2009/10/22 Andrus Adamchik So we are down to 5 Jiras in 3.0 list and 0 Jiras in B1 list. Andrus On Oct 22, 2009, at 11:04 AM, Andrus Adamchik wrote: * CAY-1067: changed issue to type to "Bug" (which it is), so we can work on it while in Beta. * CAY-1141: related to inheritance, rescheduled. * CAY-1152: may fix while in Beta, or may reschedule * CAY-1162: closed as "Won't Fix". This was related to inheritance work that got postponed. * CAY-1165: changed fix version to "Unknown". This is really low priority. * CAY-1191: partially done. Per Andrey there are still some problems. Will hopefully fix them while in Beta. * CAY-1239: rescheduled to 3.1 * CAY-1260: Mostly done, but still some rough spots remain. Planning to finish it while in Beta. * CAY-1280: rescheduled to 3.1 per our conversation with Evgeny on this list * CAY-1287: this is a documentation issue Andrus On Oct 22, 2009, at 2:36 AM, Aristedes Maniatis wrote: On 21/10/09 6:32 PM, Andrus Adamchik wrote: One more task left to do - update the user guide with things that changed from M6 and sync it to SVN. I will hopefully do that over the weekend and then assemble artifacts for a vote. Andrus What are we going to do with https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310903&fixfor=12313971 and https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310903&fixfor=12313760 Also is CAY-1260 done? It would be great to move everything in Jira to the right versions so it is clear exactly what is left to do. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A -- Andrey
Re: release countdown
Hi Malcolm, Record it under docs/doc/src/main/resources/RELEASE-NOTES.txt and close it in Jira with B1 fix version. That should be it. Thanks, Andrus On Oct 22, 2009, at 1:02 PM, Malcolm Edgar wrote: Hi Guys, Sorry for being a bit tardy on this one (SQL Server TOP fetch limit): https://issues.apache.org/jira/browse/CAY-1244 This patch has been applied, what else do I need to do to complete this. regards Malcolm Edgar On Thu, Oct 22, 2009 at 8:41 PM, Andrus Adamchik > wrote: Exactly. This is why I am suggesting to reschedule all things that have a potential of delaying 3.0. A final release till the end of the year will depend on how many bug reports we get. It is definitely doable with the current task queue, but we don't know what else will show up during Beta. Assuming with the best case scenario, I feel like we still need to have at least 2 releases before the final - B1 and RC1. Andrus On Oct 22, 2009, at 12:09 PM, Andrey Razumovsky wrote: I suggest we release final 3.0 until the end of the year. It was a long time since last official release, after all 2009/10/22 Andrus Adamchik So we are down to 5 Jiras in 3.0 list and 0 Jiras in B1 list. Andrus On Oct 22, 2009, at 11:04 AM, Andrus Adamchik wrote: * CAY-1067: changed issue to type to "Bug" (which it is), so we can work on it while in Beta. * CAY-1141: related to inheritance, rescheduled. * CAY-1152: may fix while in Beta, or may reschedule * CAY-1162: closed as "Won't Fix". This was related to inheritance work that got postponed. * CAY-1165: changed fix version to "Unknown". This is really low priority. * CAY-1191: partially done. Per Andrey there are still some problems. Will hopefully fix them while in Beta. * CAY-1239: rescheduled to 3.1 * CAY-1260: Mostly done, but still some rough spots remain. Planning to finish it while in Beta. * CAY-1280: rescheduled to 3.1 per our conversation with Evgeny on this list * CAY-1287: this is a documentation issue Andrus On Oct 22, 2009, at 2:36 AM, Aristedes Maniatis wrote: On 21/10/09 6:32 PM, Andrus Adamchik wrote: One more task left to do - update the user guide with things that changed from M6 and sync it to SVN. I will hopefully do that over the weekend and then assemble artifacts for a vote. Andrus What are we going to do with https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310903&fixfor=12313971 and https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310903&fixfor=12313760 Also is CAY-1260 done? It would be great to move everything in Jira to the right versions so it is clear exactly what is left to do. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A -- Andrey
Branches, tags
Just created a 3.0 STABLE branch, and 3.0B1 release tag. So update your local checkouts accordingly: 1. https://svn.apache.org/repos/asf/cayenne/main/trunk/ SVN trunk now corresponds to the future 3.1 release. 2. https://svn.apache.org/repos/asf/cayenne/main/branches/STABLE-3.0/ SVN "STABLE-3.0" branch now corresponds to the 3.0 release. All the Modeler improvements as well as bug fixes should go on this branch. Otherwise it is now in the core code freeze mode, so no new development of the Cayenne core is allowed here. Also, don't forget to update the trunk with anything you check in here. 3. https://svn.apache.org/repos/asf/cayenne/main/tags/3.0B1/ Beta 1 release tag. Ideally no commits (except for pom changes) should go in here... unless we find serious bugs during the release vote. Release artifacts will be posted shortly. Andrus
Re: [jira] Closed: (CAY-1260) (Exerimental) Modeler support for embeddables and embedded attributes
This is an ORM concept inspired in Cayenne by the JPA spec (the term is taken from JPA as well). An embeddable is a reusable compound ObjAttribute type that maps to multiple DbAttributes. E.g. if you have "person" and "organization" tables, that both have address columns in them (address1, address2, city, etc.). You can create an embeddable "Address", and then use it in both Person and Organization entities as a single attribute, even though it maps to multiple columns. We do need a docs entry on that. Hopefully will catch up during beta. Andrus On Oct 25, 2009, at 3:38 PM, Andrey Razumovsky wrote: Hi Andrus, Are there any docs about embeddables? I suppose I'm not the only one who doesn't know what it is :) Thanks, 2009/10/25 Andrus Adamchik (JIRA) [ https://issues.apache.org/jira/browse/CAY-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrus Adamchik closed CAY-1260. Resolution: Fixed Fix Version/s: (was: 3.0) 3.0 beta 1 (Exerimental) Modeler support for embeddables and embedded attributes - Key: CAY-1260 URL: https://issues.apache.org/jira/browse/CAY-1260 Project: Cayenne Issue Type: Task Components: CayenneModeler GUI Affects Versions: 3.0 Reporter: Andrus Adamchik Assignee: Andrus Adamchik Fix For: 3.0 beta 1 Attachments: 0001-CAY-1260.patch, Embeddable.txt, Embeddable1.txt, icon-embeddable.gif, icon-new_embeddable.gif, Inspector1_5.txt, InspectorObjAttrAndEmbAttributes.txt, InspectorObjAttrAndEmbAttributes.txt Need to implement Modeler support for mapping embeddable objects and including them in ObjEntities. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Andrey
[VOTE] Apache Cayenne release 3.0B1
Release artifacts are posted here: http://people.apache.org/~aadamchik/release/3.0B1/ Please evaluate and cast your votes. Cheers, Andrus
Re: IOC container
I've been pondering on how a Cayenne IoC "bridge" might work. My initial idea was something like an inverted "commons-logging". Spring/ Guice/Tapestry users would explicitly bind a Cayenne stack to a respective container using some "binder" class that we provide, specific to each container (unlike commons-logging that tries to guess the environment, causing occasional grief). In the absence of an external container Cayenne will use a very simple bundled container, essentially a map of interfaces vs services loaded from a classpath file. There's also a JSR-330 that aims at standardizing injection annotations: http://www.infoq.com/news/2009/08/dependency-injection-javaee6 And I just discovered that both Spring (3.0RC1) and Juice (trunk) support the annotations from this JSR. So it could make sense for us to use these annotations internally as well. Couldn't dig any info on the Tapestry IoC support for this JSR, but they are on the JSR "support group", so at least they are watching it. Anyways, will need to experiment with it a bit and see how easy it is to redefine internal Cayenne "services" from the application. Andrus On Jun 3, 2009, at 3:02 PM, Andrus Adamchik wrote: Right... I envision lots of trouble integrating this into regular JEE ecosystem. My current idea is to use built-in container only if an app has no other container, and load Cayenne configs via an app container otherwise, so that there's only one configuration registry. Andrus On Jun 3, 2009, at 2:42 PM, Malcolm Edgar wrote: One concern I have about introducing a 3rd party IoC container is class loader conflicts which may occur with including a popular IoC container. As Cayenne may have a dependency on version X but the application uses version Y. regards Malcolm Edgar On Wed, Jun 3, 2009 at 6:03 AM, Andrus Adamchik > wrote: I have a good opinion about Tapestry IoC approach in general (including the now defunct Hivemind), and I wanted to investigate Guice. There's some conflicting requirements to address here - we don't want to write/maintain our own IoC container, yet, we don't want to embed a huge third-party engine, of which we'll use only a subset of features. I'd like it to work standalone, as well as be able to integrate (or at least play well) with popular IoC containers (how many containers in one app is too many?). Then there's a matter of modeler support, which is adverse to annotations, and favors XML or other config files... All in all, I think assembling a core of Cayenne stack via such a container should open some interesting possibilities, beyond organizing current configuration. Andrus On Jun 2, 2009, at 6:53 PM, Robert Zeigler wrote: If you're really considering going the 3rd party ioc route, I highly recommend T5IOC. Note that configuration is (typically) done via code in T5IOC, but I find it extremely flexible & powerful, while still being simple to use (and small! :). If not that, then guice. I'd even go for pico (though preferably not). Anything but the monster that spring has become. ;) Robert On Jun 2, 2009, at 6/29:02 AM , Andrus Adamchik wrote: On Jun 2, 2009, at 4:38 PM, Andrus Adamchik wrote: Modeler support will be covered by setting class name of strategy I am afraid this approach will be rather arbitrary to the end user, so I suggest we discuss it some more before putting it in Cayenne. Marking an entity to use "soft delete" based on some criteria is a clear and understandable feature. Setting a "delete strategy" is not, and will contribute to confusion. This is totally be ok as a backend extension point, but I will hate to see that as a general use feature. In this context let me mention one idea for Cayenne 3.0 + N, that I've been thinking about for some time. I am taking this to a separate thread to avoid distraction from the soft delete discussion, which has only tangential relevance. Since we already have a bunch of extension points throughout the stack, some exposed via the Modeler (misplaced like cache JGroups config, or justified like Adapter config), and some are available only via the code, we need a way to reign them in. The standard way of doing that is via an IoC container. No, I don't want to bundle Spring with Cayenne, besides it has to integrate with the larger app ecosystem, so we still need to figure the technical details. But the point is that we will be able to provide a single place to configure all extension points, separate from the mapping. As unlike the mapping those parameters are often different for the same project, depending on the environment where it is deployed. Right now this place is cayenne.xml (and it might as well stay this way in the future), just that unlike say Spring config files,
Re: [VOTE] Apache Cayenne release 3.0B1
Of course. See my "branches, tags" email from yesterday. https://svn.apache.org/repos/asf/cayenne/main/tags/3.0B1/ On Oct 26, 2009, at 3:58 PM, Kevin Menard wrote: Hi Andrus, Is there a tag for 3.0B1? I see the branch for ongoing 3.0 development, but I can't find the 3.0B1 tag. -- Kevin On Sun, Oct 25, 2009 at 12:49 PM, 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: [VOTE] Apache Cayenne release 3.0B1
no problem. glad it worked. On Oct 26, 2009, at 4:12 PM, Kevin Menard wrote: Hmm . . . and now I do see it in the git repo. I guess I'm just having a bad morning. Again, apologies for the inattention. -- Kevin On Mon, Oct 26, 2009 at 10:09 AM, Kevin Menard wrote: Argh. My fault for not clicking the links. The tag isn't showing up in the git repo I pulled this morning. I guess I'll just go back to using SVN for now. Sorry for that. -- Kevin On Mon, Oct 26, 2009 at 10:03 AM, Andrus Adamchik wrote: Of course. See my "branches, tags" email from yesterday. https://svn.apache.org/repos/asf/cayenne/main/tags/3.0B1/ On Oct 26, 2009, at 3:58 PM, Kevin Menard wrote: Hi Andrus, Is there a tag for 3.0B1? I see the branch for ongoing 3.0 development, but I can't find the 3.0B1 tag. -- Kevin On Sun, Oct 25, 2009 at 12:49 PM, Andrus Adamchik wrote: Release artifacts are posted here: http://people.apache.org/~aadamchik/release/3.0B1/ Please evaluate and cast your votes. Cheers, Andrus
Preferences
On Oct 26, 2009, at 6:03 PM, Michael Gentry wrote: PS. I'm going to vote for 3.1 that H2 is dumped in CM. I just had to use Time Machine to restore my preferences...again. (Not the B1 CM, but I don't think it'll be better in that department.) In fact since I am actively using CM JNDI hack, I'd love us start using java standard preferences store. This way I won't have to create optional profiles to include cayenne-modeler.jar for local work. Andrus
Re: [VOTE] Apache Cayenne release 3.0B1
so you use Java 6 by any chance? On Oct 26, 2009, at 6:12 PM, Kevin Menard wrote: I'll have to dig in some more, but I just hit the following test failure using hsqldb: --- Test set: org.apache.cayenne.access.DataContextSharedCacheTest --- Tests run: 16, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.846 sec <<< FAILURE! testSnapshotEvictedAndObjectsHollowedForInvalidate (org.apache.cayenne.access.DataContextSharedCacheTest) Time elapsed: 0.008 sec <<< FAILURE! junit.framework.AssertionFailedError: expected:<5> but was:<3> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at junit.framework.Assert.assertEquals(Assert.java:207) at org .apache .cayenne .access .DataContextSharedCacheTest .testSnapshotEvictedAndObjectsHollowedForInvalidate (DataContextSharedCacheTest.java:616) -- Kevin On Sun, Oct 25, 2009 at 12:49 PM, 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: Run query NOT in transaction
Yeah, quite annoying. Here is a workaround: http://cayenne.apache.org/doc20/stored-procedures-and-transactions.html Andrus On Oct 27, 2009, at 5:54 PM, Evgeny Ryabitskiy wrote: Hello 2 everyone! I have one problem with transaction policy in Cayenne. I need to run some query without transaction. Why? I am using Temporary Tables in T-SQL which can't be created in Transaction. But Cayenne using transaction for every query. Here is example: If I run this Query: Create Table #MYTempTable (someid int) Insert Into #MYTempTable (someid) Select 0 I got: java.sql.SQLException: There was a transaction active when exiting the stored procedure ''. The temporary table '#MYTempTable' was dropped in this transaction either explicitly or implicitly. This transaction has been aborted to prevent database corruption. After some research I didn't find any ability to turn off transaction for query. Maybe it will be nice to add some API parameter to change this behavior? ) Evgeny Ryabitskiy.
Re: Run query NOT in transaction
On Oct 27, 2009, at 6:15 PM, Evgeny Ryabitskiy wrote: The problem that as usual I need to turn it off only in some "special cases". Usual I am using InternalTransaction API. Using of ProcedureQueries is not a solution in my case, we prefer common RowQuery. :) Sure, this is applicable to any type of query though. It' a solution to replace InternalTransaction by ExternalTransaction (which actually do nothing) in such "special cases", so it' helps. I just got this solution in mind. But it's not so intuitive... and really ugly... Good to know that the workaround helps you. I will add issue on 3.1 Transaction mechanism is not a best part of Cayenne :( I both agree and disagree. I disagree with the general statement. Implicit transaction mechanism is actually the best part of Cayenne 99% of the time compared to alternatives. I.e. you don't have to manage transaction at all. I agree that in such edge cases it can and should do better. Andrus
Re: [VOTE] Apache Cayenne release 3.0B1
The version update was needed to remap renamed callbacks. So if you upgrade a schema with "prePersist" callback, you'll see more changes. I mentioned this on the list before - since there's generally no direct correspondence between Cayenne runtime version and project schema version, I figured I'd come up with some numbering scheme that can't be mistaken for a Cayenne runtime version. So 3.0.0.1 is pretty random based on the fact that we may have 3.0.1 Cayenne release, but not a 3.0.0.1. Also this does not affect the XSD schema version. I simply updated the existing schema. I think of the schema as a Java class - during 3.0 development cycle we are allowed to change it without changing the version. It does look counterintuitive somewhat, but allows us to modify the schema and implement automated XML upgrades between the milestone releases. Andrus On Oct 28, 2009, at 4:03 PM, Aristedes Maniatis wrote: On 26/10/09 3:49 AM, Andrus Adamchik wrote: Release artifacts are posted here: http://people.apache.org/~aadamchik/release/3.0B1/ Please evaluate and cast your votes. One smallish issue. When it opened my model, it 'upgraded' it from version 3.0 to 3.0.0.1. What is the versioning scheme we are using here? Why 3.0.0.1? How does that relate to the XSD schema which is currently set to version 3.0. Here is the only change made by the modeller when opening a model previously saved with M6... http://cayenne.apache.org/schema/3.0/modelMap"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; - xsi:schemaLocation="http://cayenne.apache.org/schema/3.0/modelMap http://cayenne.apache.org/schema/3.0/modelMap " - project-version="3.0"> + xsi:schemaLocation="http://cayenne.apache.org/schema/3.0/modelMap http://cayenne.apache.org/schema/3.0/modelMap.xsd " + project-version="3.0.0.1"> Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: [VOTE] Apache Cayenne release 3.0B1
The real problem is that the Modeler tells you that the model is being upgraded to "version 3.0.0.1". Which means nothing to the user. Let's just tell the user that the model was updated and leave it at that. This model you opened was previously saved with an older version of Cayenne Modeler and has now been upgraded. You should verify the changes and, if necessary, regenerate your Java class files. Agreed, we should change the message to hide the dummy version number. I guess we can make this change during the Beta. If we need an internal number which increments so that we know how to upgrade the schema, right through the development process, then it should be internal and not exposed to the user. I'd suggest a simple incrementing integer which doesn't look at all like the Cayenne version. Let's start at (say) 100 and go from there. Agreed. Maybe let's implement this approach the next time we need to bump the schema. Ideally this message would only appear if some change was actually made to the model. I sort of wanted it to be very explicit and preempt any attempts to work on the model. I guess we can use some mixed approach - show a warning on opening the project, but avoid saving the new version right away. Just put the project in a dirty state, upgrade it in memory, and change the disk files only when the user hits save. Andrus On Oct 29, 2009, at 12:59 AM, Aristedes Maniatis wrote: On 29/10/09 1:18 AM, Andrus Adamchik wrote: The version update was needed to remap renamed callbacks. So if you upgrade a schema with "prePersist" callback, you'll see more changes. Ah, I wasn't paying attention. I remember now. I better regenerate our schema docs for the web site. I mentioned this on the list before - since there's generally no direct correspondence between Cayenne runtime version and project schema version, I figured I'd come up with some numbering scheme that can't be mistaken for a Cayenne runtime version. So 3.0.0.1 is pretty random based on the fact that we may have 3.0.1 Cayenne release, but not a 3.0.0.1. Yes, but this is a bit confusing. If we need an internal number which increments so that we know how to upgrade the schema, right through the development process, then it should be internal and not exposed to the user. I'd suggest a simple incrementing integer which doesn't look at all like the Cayenne version. Let's start at (say) 100 and go from there. The real problem is that the Modeler tells you that the model is being upgraded to "version 3.0.0.1". Which means nothing to the user. Let's just tell the user that the model was updated and leave it at that. This model you opened was previously saved with an older version of Cayenne Modeler and has now been upgraded. You should verify the changes and, if necessary, regenerate your Java class files. Ideally this message would only appear if some change was actually made to the model. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: release folder structure
On Oct 29, 2009, at 11:11 AM, Aristedes Maniatis wrote: In the OSX dmg I can see several files I don't understand. cayenne-agent.jar This was for class enhancement. Since the POJOs are not really working in 3.0, we can remove it from the future betas. cayenne-tools.jar Ant tasks. We don't want them in the main Jar, because they have lots of specific dependencies that we don't want to be attached by Maven to the user apps. cayenne-modeler.jar Well, I do understand the last one, but I don't know why it is there since we already ship CayenneModeler.app. This is a CayenneModeler "library" used for JNDI hack: http://cayenne.apache.org/doc/local-datasources.html I hope we can strip the read-JNDI-from-preferences code out of the modeler, but this is pending a decision on Modeler preferences format in general. Also, why do we have META-INF inside the src directory? Let's get rid of it. +1. I'd like to see the 'dotemplates' folder renamed to "entity templates" (hey this is 2009 we are allowed to use spaces) and placed at the top level. We are, but we'll probably get punished for it in some unforeseen ways :-) We can just call it "templates" going forward. Finally, let's remove the cayenne-3.0B1 folder. So the results would be like this: cayenne.dmg - CayenneModeler.app - lib - cayenne-client-3.0.jar ... I sort of like that I can mount a DMG, then drag the Modeler to desktop, and drag cayenne-3.0B1 to the folder where I keep other similar libraries. Looks very intuitive to me. Andrus
Re: [VOTE] Apache Cayenne release 3.0B1
Eclipse also doesn't like it, and breaks on anything EJBQL related. But once I build everything with Maven and refresh in Eclipse, things start to work again. I know we need to fix it. Just saying why this hasn't been a priority. Andrus On Oct 29, 2009, at 3:44 PM, Kevin Menard wrote: My vote is -0. It seems others are able to build it, but I can't. I just ran into another issue where the jjtree generation seems to be duplicating the package name. So, I end up with paths like "framework/cayenne-jdk1.5-unpublished/target/generated-sources/ jjtree/org/apache/cayenne/ejbql/org/apache/cayenne/ejbql/parser/", which don't match the package name. IDEA does not like this, maven doesn't seem to mind. I recall seeing this before, but I thought it got fixed. No doubt the test failure is related to my snow leopard upgrade, because all tests were passing before then. I'm not sure how long the parser thing has been like this. Older versions of IDEA may have been more tolerant of the bad package name and I've been tracking the EAPs. -- Kevin On Thu, Oct 29, 2009 at 9:34 AM, Tore Halset wrote: 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: Making sense of callbacks
Andrey do have time to check that? If not I may try investigating it over the weekend (although I never used callbacks with ROP, so I am not fully sure how they are expected to work). This may warrant a release recall. Andrus On Oct 30, 2009, at 4:43 AM, Lachlan Deck wrote: Hi Andrus, On 04/10/2009, at 12:37 AM, Andrus Adamchik wrote: I finished this per CAY-1281. Project upgrade is performed on opening it in the Modeler, so migration for the existing callback users is straightforward. Haven't checked whether that works for ROP. I would appreciate if somebody could help me with that. I can confirm that this is broken (unless I've missed something obvious) in ROP after updating to 3.0B1 After the update it appears that an entity record is not properly initialised when saving from ROP. i.e., server-side validation is throwing some NPEs and/or thinking that values haven't been set (perhaps a serialisation issue?). However, the validation on the client-side would have caught this as, for the most part, the validation is the same. I refactored all our current server-side prePersist methods to postAdd and the problem saving from the client continues. Rolling back the cayenne jar(s) fixes the problem. Any suggestions? On Sep 28, 2009, at 9:53 AM, Andrus Adamchik wrote: On Sep 28, 2009, at 4:08 AM, Lachlan Deck wrote: So from what I can see the only two changes required were 'postInsert' and adjusting the meaning of prePersist I also tend to think that less is better. This discussion thread was a nice brainstorming on the callbacks use patterns. So we've played with a few things and now I am fine if we go a full circle to the minimal change suggested earlier, and don't worry about JPA users, extra delete callbacks, or symmetry between callback types (in many respects there's little symmetry if you look at the object lifecycle - http://cayenne.apache.org/doc/persistent-object-lifecycle.html) . So here is the change I am going to make: 1. Call "prePersist" before commit 2. Introduce "postAdd" instead of current "prePersist". This change is minimal and is not incompatible with other ideas. Objections? Andrus with regards, -- Lachlan Deck
Re: Making sense of callbacks
On Oct 30, 2009, at 10:57 AM, Andrey Razumovsky wrote: This is not about callbacks on client-side - as far as I know, we don't have callbacks on ROP. Ah great. I wasn't sure about the status of that. If I understand correctly, "prePersist" isn't invoked for server-side temporary objects when committing from client. I'll try to do that on the weekend, but I'm not sure Let me know. I can take a look as well if needed. Andrus
Re: Changed PK Typecasting?
Hi Dave, thanks for tracking this down. Now that you've mentioned a specific commit, it all makes sense to me know. My take on this though is that it is working correctly now, and was working before purely by accident. So I guess I'll just add a note to the UPGRADE-NOTES.txt, but I don't think we should roll back this behavior. BTW going through my mailbox, I've seen the exact same PG Exception when trying to bind a String to a boolean parameter back in July 2007. So we are actually getting more consistent now, with all types working the same way. Andrus On Oct 30, 2009, at 12:40 PM, Dave Dombrosky wrote: Andrus, I finally looked into this, and I found the problem. I opened up https://issues.apache.org/jira/browse/CAY-1298 for the bug. It's not a major regression, but it could be annoying for users upgrading from earlier versions of Cayenne. -Dave On Sun, Sep 27, 2009 at 9:34 AM, Andrus Adamchik > wrote: I don't recall an intentional change to disable automated type conversion. It was not supported before, so I guess it was purely coincidental that it worked on a particular database with a particular driver. Andrus On Sep 25, 2009, at 11:46 AM, Dave Dombrosky wrote: Trying to use the latest trunk code, I came across some behavior that has changed. I used to be able to pass DataObjectUtils.objectForPK a primary key that was a String, and Cayenne would automatically typecast this to the real PK type (such as String -> Integer). Now it seems like the typecasting does not occur, causing an exception on the query with my database. Was this change intentional? If not, I'll open a bug report with more detail. -Dave
Re: Making sense of callbacks
On Oct 30, 2009, at 11:21 PM, Lachlan Deck wrote: I refactored these (after the jar update) to postAdd (when noticing that it wasn't working anymore .. and checked the mail archives for what Andrus had committed) ... and found that things weren't working either way until I rolled back the jar update. Actually no refactoring should is needed. Just open the model in the new CayenneModeler and agree to perform an upgrade. It will remap (in the XML) the existing Java method names to the right callbacks. Or do you configure callbacks in the code, not the model? Andrus
Re: [VOTE] Apache Cayenne release 3.0B1
Excellent! I will rebuild the release artifacts (maybe even delete the tag, and create a fresh tag from STABLE, as it contains substantial bug fixes from last week), but let's wait till we come to some conclusion on the Lachlan's issue. Andrus On Nov 2, 2009, at 8:59 AM, Andrey Razumovsky wrote: Done. Andrus, could you rebuild the artifacts? Sorry for the noise 2 ноября 2009 г. 10:09 пользователь Andrey Razumovsky < razumovsky.and...@gmail.com> написал: Found a major regression - sometimes modeler shows an error when deleting DbRelationship. Please hold the release until I fix it 30 октября 2009 г. 23:53 пользователь Kevin Menard >написал: Hi Andrey, That did the trick. Thanks. -- Kevin 2009/10/30 Andrey Razumovsky : Hi Kevin, I've replaced on line 608 of DataContextSharedCacheTest Thread.sleep(1); to Thread.sleep(10); Now it seems the test isn't failing for me. Please try this, I'll commit if it helps 28 октября 2009 г. 17:48 пользователь Kevin Menard Thanks. This further supports Andrey's theory that it's a non-specified ordering issue. I should be able to fix it tonight. -- Kevin 2009/10/28 Ольга Ткачева : Oh, I use Fedora release 10 (Cambridge) 2009/10/28 Ольга Ткачева I run tests on Java 1.6 ]$ java -version java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode) I don't have errors. 2009/10/26 Kevin Menard Yeap. ~/dev/workspaces-java/cayenne(3.0B1) $ java -showversion java version "1.6.0_15" Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode) This is on Snow Leopard 10.6.1. -- Kevin On Mon, Oct 26, 2009 at 12:17 PM, Andrus Adamchik wrote: so you use Java 6 by any chance? On Oct 26, 2009, at 6:12 PM, Kevin Menard wrote: I'll have to dig in some more, but I just hit the following test failure using hsqldb: --- Test set: org.apache.cayenne.access.DataContextSharedCacheTest --- Tests run: 16, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.846 sec <<< FAILURE! testSnapshotEvictedAndObjectsHollowedForInvalidate (org.apache.cayenne.access.DataContextSharedCacheTest) Time elapsed: 0.008 sec <<< FAILURE! junit.framework.AssertionFailedError: expected:<5> but was:<3> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java: 282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at junit.framework.Assert.assertEquals(Assert.java:207) at org .apache .cayenne .access .DataContextSharedCacheTest .testSnapshotEvictedAndObjectsHollowedForInvalidate (DataContextSharedCacheTest.java:616) -- Kevin On Sun, Oct 25, 2009 at 12:49 PM, Andrus Adamchik wrote: Release artifacts are posted here: http://people.apache.org/~aadamchik/release/3.0B1/<http://people.apache.org/%7Eaadamchik/release/3.0B1/ > <http://people.apache.org/%7Eaadamchik/release/3.0B1/> <http://people.apache.org/%7Eaadamchik/release/3.0B1/> Please evaluate and cast your votes. Cheers, Andrus -- Olga -- Olga -- Andrey -- Andrey -- Andrey
Re: [jira] Commented: (CAY-1300) Format queries in QueryLogger
Agreed - a good idea. This is one of those cases were I feel like we need some minimal IoC to be able to manage Cayenne extensions. Until we have it, -Dcayenne.query.formatting is the way to go. Andrus On Nov 2, 2009, at 5:36 AM, Andrey Razumovsky (JIRA) wrote: [ https://issues.apache.org/jira/browse/CAY-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772412 #action_12772412 ] Andrey Razumovsky commented on CAY-1300: The idea is excellent. May I suggest that all JOINs are also formatted to be placed on new line? Some sort of QueryFormatter will also be fine. Also using ThreadLocal for setting "isFormatting" property forces to make this call at any request to format queries. So I think it'll be a good idea to have some static default value for "isFormatting", set by a static call or by adding something like "-Dcayenne.query.formatting=true" to command line Format queries in QueryLogger - Key: CAY-1300 URL: https://issues.apache.org/jira/browse/CAY-1300 Project: Cayenne Issue Type: New Feature Components: Cayenne Core Library Reporter: Evgeny Ryabitskiy Fix For: 3.0 Attachments: CAY-1300.patch Sometimes it's hard to read queries from Logs when queries are huge. It will be nice if user can enable nice query formatting for debug purposes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Apache Cayenne release 3.0B1
Same here. On Nov 2, 2009, at 10:07 AM, Andrey Razumovsky wrote: Actually, no. My test shows everything's all right, so some more info is required 2 ноября 2009 г. 14:01 пользователь Aristedes Maniatis написал: On 2/11/09 6:52 PM, Andrus Adamchik wrote: I will rebuild the release artifacts (maybe even delete the tag, and create a fresh tag from STABLE, as it contains substantial bug fixes from last week), but let's wait till we come to some conclusion on the Lachlan's issue. I'm not sure if Lachlan will be online tonight, but do you have enough information about this issue? Because I'm really busy with other things, I haven't been following along in detail, but I can ask Lachlan to spend some time at work tomorrow (in about 14 hours from now) to help create a test case. Unless you already have a clear lead on what needs looking at. Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A -- Andrey
Eclipse vs. Swing (Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler)
Here is one of those "big strategy" emails that tend to have negative impact on things that we can do here and now, instead of doing the "right" thing some time later. So no intent to discourage CAY-762 implementation, just a somewhat related issue that we may discuss in parallel. For all its undeniable advantages, IMO the main usability issue with CayenneModeler is the fact that it is separate from an IDE. This "gap" results in the following problems: 1. Losing work context when switching between the apps: You have to often jump between the IDE and the Modeler. When switching, you lose your work context. E.g. click on a Java class name within some code, the class opens... Then you'd like to see its Cayenne mapping. To do that, you have to go to a different application, type something in a search box, open the entity, then tab between attributes/relationships, then look for DbEntity, tab between attributes/relationships again. It is too far away from the original Java class. I'd like to see Java/XML/Modeler representations of the same entity in the same view. 2. Manual Refresh When the model is saved, you have to refresh files in IDE to pick up the change. 3. Class Generation: You need to generate classes manually on model change, then refresh files in the IDE. For Maven/Eclipse users cgen problem is somewhat addressed, as you can tie cgen to Maven, and Maven to Eclipse, so classes are generated on refresh. Still you have to do refresh, and then a second refresh (first refresh for xml, second for the generated classes - totally annoying). The best way to address the gap is to write an IDE plugin replacing the Modeler. There's a bunch of advantages and disadvantages to that: [good] * everything is integrated * Eclipse environment provides lots of built in services that we can take advantage of (most notably it has a built in project model), including graph capabilities. [bad] * not everybody's using Eclipse (e.g. Kevin mentioned he's an IDEA user). Supporting multiple IDE's is not realistic for us. I guess this can be addressed by packaging it into a standalone SWT app. * we'll have to support multiple versions of Eclipse, and will be dependent on Eclipse API evolution. [ugly] * the time we invested in the Modeler. Reproducing that in Eclipse would be non-trivial. Or we can go with some hybrid approach of having an Eclipse plugin exchanging events with the Modeler. Not sure if we can make the user experience as nice, we'll have to support 2 tools instead of 1, and we'll have to support an extra messaging layer. But this is probably less work overall... Or we can write an Eclipse plugin in parallel with the Modeler and provide both as independent tools... Such internal competition will be a resource drain though. So nothing is free, and these are some hard choices... I am sort of in favor of the last one, as even an initial plugin prototype will show whether we can have significant usability improvements, without being a full Modeler replacement. Andrus On Oct 22, 2009, at 10:40 AM, Andrey Razumovsky (JIRA) wrote: [ https://issues.apache.org/jira/browse/CAY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768592 #action_12768592 ] Andrey Razumovsky commented on CAY-762: --- FYI JGraph has moved to BSD since 5.13: http://www.jgraph.com/jgraphlog.html I assume this means we can now use it? The library seems to be quite promising ERDiagram for Object Entities in Cayenne Modeler Key: CAY-762 URL: https://issues.apache.org/jira/browse/CAY-762 Project: Cayenne Issue Type: New Feature Components: CayenneModeler GUI Affects Versions: 3.0 Reporter: Ahmed Mohombe Assignee: Andrus Adamchik Please add an ER Diagram to the Cayenne Modeler. This is the feature that I miss the most from WebObjects. For start it would be even enough to have an ER Diagram View (so no interactive activities) - just display and layout of entities. I think this would help allot and would increase the productivity with CM - most people think visually. I don't think that it would be complicated to implement, the most complicated question to answer is what graph library is allowed to use, due to the restrictive "license compatibility" of the Apache license. Thanks in advance, Ahmed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Eclipse vs. Swing (Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler)
On Nov 2, 2009, at 11:07 AM, Aristedes Maniatis wrote: Well, there already is an ugliness that quite a bit of Modeler specific code lives in the main Cayenne jar. So pulling that out into a ui-core library is probably the first step. Should the main Cayenne jar even know how to *write* the model into an XML file? Agree. We can have a cayenne-project module (i.e. something not belonging to either GUI or runtime). Is there a possibility to work with the WOlips people on this? And they are sure to chip in on the idea of writing a GUI ERDiagram tool. But is EOF just too different to make it work? That would've been ideal, but likely won't work. IIRC Mike from WOLips commented on that at one point, saying it is not possible to have a single tool for both Cayenne and EOF. I think he looked at the Modeler initially (or maybe even used some of the code?) but couldn't keep it as a common library due to lots of "small" differences. Still probably worth pinging WOLips community to get some feedback on the idea. Andrus
Re: Eclipse vs. Swing (Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler)
On Nov 2, 2009, at 12:17 PM, Andrey Razumovsky wrote: Once again, I'm all for Cayenne-Eclipse plugin, but I'm sceptical about its future in current state of Cayenne community I agree with this assessment. On the other hand there is a chance that starting a prototype will cause interest in the community and we'll get dedicated participants. This is a case of "build it and they'll come". E.g. Apache Click project has a simple Cayenne plugin. Maybe we can collaborate with them somehow. So there's hope (and there's also Summer of Code next year ;-)). I am no Eclipse platform guru either, and have very little time, but I am interested enough to start poking and prototype a plugin that does something that Modeler doesn't. So that it will be a nice-to-have plugin for Cayenne users, even though it does not substitute the Modeler. This may generate some interest (or not). But yeah, I agree with you, and let's step carefully and try not to overcommit ourselves to something that we can't deliver. Andrus
Re: Eclipse vs. Swing (Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler)
On Nov 2, 2009, at 12:53 PM, Bob Schellink wrote: Preferences > General > Workspace > Refresh Automatically Haven't tried it, but looks like something that would cause race conditions, conflicting with command line builds, git updates, etc. Andrus
Re: Eclipse vs. Swing (Re: [jira] Commented: (CAY-762) ERDiagram for Object Entities in Cayenne Modeler)
On Nov 2, 2009, at 2:42 PM, Kevin Menard wrote: At that point, you'd be much better off building it as an RCP app and then looking to integrate that with Eclipse. That's what I was thinking about. Andrus
Re: CAY-1249 CM: Top menus disappearing after reverse engineering
I don't see it anymore either. So hopefully that was something that Apple fixed. Andrus On Nov 2, 2009, at 4:45 PM, Michael Gentry wrote: Andrus, I haven't noticed this issue in 3.0B1's modeler (and I've done several schema generations). Perhaps the issue got fixed or an OS X Java update (I'm on Leopard -- 10.5.8) solved it? I definitely noticed the issue a while back using the 3.0M6 modeler, as did others here. mrg java -version java version "1.5.0_20" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_20- b02-315) Java HotSpot(TM) Client VM (build 1.5.0_20-141, mixed mode, sharing)
Re: CAY-1249 CM: Top menus disappearing after reverse engineering
On Nov 2, 2009, at 4:51 PM, Michael Gentry wrote: I say we move the issue to resolved/closed unless it pops up again. Anyone else agree? +1. In fact I just closed it as "Can't reproduce" Andrus
[RECALLED] Re: [VOTE] Apache Cayenne release 3.0B1
So Lachlan just confirmed that there's no issue with callbacks. We are cleared to go ahead with the release. However since there were a few new bugs discovered and fixed in the last week, I am recalling this vote, and will tag 3.0-STABLE branch one more time and post the new artifacts somewhere between today and Thursday morning. Hopefully the second vote will take less time. Thanks everybody for doing such a thorough evaluation. Andrus On Oct 25, 2009, at 6:49 PM, 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: [VOTE] Apache Cayenne release 3.0B1
Guys, see my RECALL email. I suggest that we include accumulated fixes and redo the release. Andrus On Nov 3, 2009, at 11:49 AM, Malcolm Edgar wrote: +1 preliminary testing we have done indicated no problem with our applications regards Malcolm Edgar 2009/11/3 Aristedes Maniatis : On 2/11/09 6:52 PM, Andrus Adamchik wrote: I will rebuild the release artifacts (maybe even delete the tag, and create a fresh tag from STABLE, as it contains substantial bug fixes from last week), but let's wait till we come to some conclusion on the Lachlan's issue. Lachlan spent some time on this today and identified the cause of the problem. It was purely within our code and so Cayenne is exonerated from the problem. It was triggered by the change in lifecycle naming, which is why it was evident only with the new release. Anyhow, onward with the beta release! Regards Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
maven-javadoc-plugin slowness
Not sure what happened and whether we used a different version of the javadoc plugin before, but the last couple of weeks doing a full Cayenne build is taking forever, with the following output generated for all the modules for which we don't have Javadocs: [INFO] Building Cayenne Documentation [INFO]task-segment: [clean, install] [INFO] INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin: 2.6:javadoc' has not be previously called for the project: 'org.apache.cayenne.itests:pojo:jar:3.0B1'. Trying to invoke it... [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin: 2.6:javadoc' has not be previously called for the project: 'org.apache.cayenne.itests:jpa-chapter2:jar:3.0B1'. Trying to invoke it... [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin: 2.6:javadoc' has not be previously called for the project: 'org.apache.cayenne.itests:jpa-chapter3:jar:3.0B1'. Trying to invoke it... ... The actual JavaDocs generation for those modules that actually need it is rather fast, but the noop execution above is *extremely* slow. Andrus
[VOTE] Apache Cayenne release 3.0B1 - take 2
Just posted fresh artifacts: http://people.apache.org/~aadamchik/release/3.0B1/ Please cast your votes. Thanks, Andrus
Re: [VOTE] Apache Cayenne release 3.0B1 - take 2
Guys, I know it may be too much trouble to evaluate two releases in a row, but can we take a look at the new artifacts please? Thanks, Andrus P.S. Here is my +1 On Nov 3, 2009, at 10:17 PM, Andrus Adamchik wrote: Just posted fresh artifacts: http://people.apache.org/~aadamchik/release/3.0B1/ Please cast your votes. Thanks, Andrus
Re: [VOTE] Apache Cayenne release 3.0B1 - take 2
On Nov 6, 2009, at 10:15 AM, Aristedes Maniatis wrote: When I take an MD5 hash of the client and server jars, I find that nothing at all changed between the previous beta and this beta. If that is expected, then I'm +1 No, MD5s should not match the first round of B1 jars. First, of course there were changes. But even if there was no changes, maven creates some metadata files with timestamps in the jars, so just rebuilding a jar from the same codebase would result in a different checksum. Andrus
Re: [VOTE] Apache Cayenne release 3.0B1 - take 2
Ok, the vote has been running for almost 6 days. Thanks everybody for taking time to evaluate it for the second time. Here is the tally: Andrus Adamchik +1 Tore Halset +1 Andrey Razumovsky +1 Aristedes Maniatis +1 Robert Zeigler +1 Michael Gentry +1 Malcolm Edgar +1 Kevin Menard +1 So the release is officially approved. I am going to post the artifacts and update the download page. I assume Ari will do the announcements. (BTW, is the confluence autoexport template problem solved, as we'll need to update the release status in the site menu?). Thanks, Andrus On Nov 3, 2009, at 10:17 PM, Andrus Adamchik wrote: Just posted fresh artifacts: http://people.apache.org/~aadamchik/release/3.0B1/ Please cast your votes. Thanks, Andrus
Maven repo deploy permissions
Kevin,
could you please update file permissions on the files that you created
in the repo per these instructions on people.apache.org:
/www/people.apache.org/repo/m2-ibiblio-rsync-repository/README.txt:
find /www/www.apache.org/dist/maven-repository/org/apache/cayenne ! -
perm 775 -type d -user kmenard -exec chmod 775 {} \;
find /www/www.apache.org/dist/maven-repository/org/apache/cayenne ! -
perm 664 -iname "maven-metadata.xml*" -user kmenard -exec chmod 664 {}
\;
find /www/www.apache.org/dist/maven-repository/org/apache/cayenne ! -
perm 644 ! -iname "maven-metadata.xml*" -type f -user kmenard -exec
chmod 644 {} \;
Otherwise I am getting the following error:
[INFO] Error installing artifact's metadata: Error while deploying
metadata: Error occurred while deploying 'org/apache/cayenne/plugins/
maven-cayenne-modeler-plugin/maven-metadata.xml' to remote repository:
scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-
repository: SCP terminated with error: 'scp: /www/people.apache.org/
repo/m2-ibiblio-rsync-repository/org/apache/cayenne/plugins/maven-
cayenne-modeler-plugin/maven-metadata.xml: Permission denied'
Thanks,
Andrus
Re: Maven repo deploy permissions
Sorry, the correct repo path is this in the instructions from the
previous message:
/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/
cayenne/
Andrus
On Nov 9, 2009, at 12:29 PM, Andrus Adamchik wrote:
Kevin,
could you please update file permissions on the files that you
created in the repo per these instructions on people.apache.org:
/www/people.apache.org/repo/m2-ibiblio-rsync-repository/README.txt:
find /www/www.apache.org/dist/maven-repository/org/apache/cayenne ! -
perm 775 -type d -user kmenard -exec chmod 775 {} \;
find /www/www.apache.org/dist/maven-repository/org/apache/cayenne ! -
perm 664 -iname "maven-metadata.xml*" -user kmenard -exec chmod 664
{} \;
find /www/www.apache.org/dist/maven-repository/org/apache/cayenne ! -
perm 644 ! -iname "maven-metadata.xml*" -type f -user kmenard -exec
chmod 644 {} \;
Otherwise I am getting the following error:
[INFO] Error installing artifact's metadata: Error while deploying
metadata: Error occurred while deploying 'org/apache/cayenne/plugins/
maven-cayenne-modeler-plugin/maven-metadata.xml' to remote
repository: scp://people.apache.org/www/people.apache.org/repo/m2-
ibiblio-rsync-repository: SCP terminated with error: 'scp: /www/
people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/
cayenne/plugins/maven-cayenne-modeler-plugin/maven-metadata.xml:
Permission denied'
Thanks,
Andrus
Re: svn commit: r834109 - /cayenne/site/trunk/tlp-site/src/confluence/auto-export-template.txt
If I am not mistaken, tinyurl's expire after some time, no? On Nov 9, 2009, at 5:33 PM, amania...@apache.org wrote: - Wiki + http://tinyurl.com/yfrrh6n";>Wiki
Re: svn commit: r834109 - /cayenne/site/trunk/tlp-site/src/confluence/auto-export-template.txt
I think I personally saw a few expired ones, assigned to something other than the original content. But I can't dig up those now. Andrus On Nov 9, 2009, at 5:39 PM, Michael Gentry wrote: From http://tinyurl.com/ ... "we will create a tiny URL that will not break in email postings and never expires." On Mon, Nov 9, 2009 at 10:35 AM, Andrus Adamchik > wrote: If I am not mistaken, tinyurl's expire after some time, no? On Nov 9, 2009, at 5:33 PM, amania...@apache.org wrote: - Wiki + http://tinyurl.com/yfrrh6n";>Wiki
Re: svn commit: r834109 - /cayenne/site/trunk/tlp-site/src/confluence/auto-export-template.txt
Like I said, I don't have an example now, so it could be anything, including just plain incorrect URL :-) On Nov 9, 2009, at 5:52 PM, Michael Gentry wrote: Well, I'm not saying they never expire. I'm just saying they claim the URLs never expire. :-) Are you sure it wasn't a tinyurl pointing to something that no longer was available? On Mon, Nov 9, 2009 at 10:44 AM, Andrus Adamchik > wrote: I think I personally saw a few expired ones, assigned to something other than the original content. But I can't dig up those now. Andrus On Nov 9, 2009, at 5:39 PM, Michael Gentry wrote: From http://tinyurl.com/ ... "we will create a tiny URL that will not break in email postings and never expires." On Mon, Nov 9, 2009 at 10:35 AM, Andrus Adamchik > wrote: If I am not mistaken, tinyurl's expire after some time, no? On Nov 9, 2009, at 5:33 PM, amania...@apache.org wrote: - Wiki + http://tinyurl.com/yfrrh6n";>Wiki
Re: Maven repo deploy permissions
Thanks, that worked. The release is now fully deployed and the
download page updated.
We can do the announcement now.
Andrus
On Nov 9, 2009, at 3:50 PM, Kevin Menard wrote:
Done. Sorry about that.
Let me know if you have any more problems.
--
Kevin
On Mon, Nov 9, 2009 at 5:31 AM, Andrus Adamchik > wrote:
Sorry, the correct repo path is this in the instructions from the
previous
message:
/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/
cayenne/
Andrus
On Nov 9, 2009, at 12:29 PM, Andrus Adamchik wrote:
Kevin,
could you please update file permissions on the files that you
created in
the repo per these instructions on people.apache.org:
/www/people.apache.org/repo/m2-ibiblio-rsync-repository/README.txt:
find /www/www.apache.org/dist/maven-repository/org/apache/
cayenne ! -perm
775 -type d -user kmenard -exec chmod 775 {} \;
find /www/www.apache.org/dist/maven-repository/org/apache/
cayenne ! -perm
664 -iname "maven-metadata.xml*" -user kmenard -exec chmod 664 {} \;
find /www/www.apache.org/dist/maven-repository/org/apache/
cayenne ! -perm
644 ! -iname "maven-metadata.xml*" -type f -user kmenard -exec
chmod 644 {}
\;
Otherwise I am getting the following error:
[INFO] Error installing artifact's metadata: Error while deploying
metadata: Error occurred while deploying
'org/apache/cayenne/plugins/maven-cayenne-modeler-plugin/maven-
metadata.xml'
to remote repository:
scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-
rsync-repository:
SCP terminated with error: 'scp:
/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/
cayenne/plugins/maven-cayenne-modeler-plugin/maven-metadata.xml:
Permission denied'
Thanks,
Andrus
Re: Maven repo deploy permissions
Looks great. I suggest to change the RELEASE-NOTES link to http://svn.apache.org/repos/asf/cayenne/main/tags/3.0B1/docs/doc/src/main/resources/RELEASE-NOTES.txt (as the target audience may be 2.0 users). And maybe also mention this: http://svn.apache.org/repos/asf/cayenne/main/tags/3.0B1/docs/doc/src/main/resources/UPGRADE.txt Andrus On Nov 9, 2009, at 11:43 PM, Aristedes Maniatis wrote: On 10/11/09 8:36 AM, Andrus Adamchik wrote: We can do the announcement now. Please review: http://cwiki.apache.org/confluence/display/CAYSITE/2009/11/09/Cayenne+3.0+beta+1+released+%2810+November+2009%29 I'm heading out to some meetings now for a big day, but if no one wants to add anything to the announcement, I'll send that out to the email lists tonight (Sydney time) and then update all the other stuff (freshmeat, wikipaedia, etc, etc) Ari -- --> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
