headers
Robert Zeigler | 1 Jul 2006 22:54

fault exception

Ok... at long last, I've a few things to report on the exception
resolving fault issue I first mentioned back in May.
Here's the brief:
Tables:
Assignment
    id: pk
    transactions: toMany to AssignmentTransactions
    parameters: toOne to AssignmentParameters
    type: used for inheritance
    unimportant attributes
AssignmentTransaction:
    id: pk
    assignment: toOne to Assignment (uses assignmentid FK)
    unimportant attributes
AssignmentParameters:
    id: pk
    assignment: toOne to Assignment (uses assignmentid FK)
    unimportant attributes

Objects:
Assignment (type is NULL)
AssignmentTransaction
AssignmentParameters
Exam (extends Assignment; type is "exam").

In the test case, which I will attach to a JIRA issue I will open, I
fetch an Exam from the database, create a transaction, and set the
transaction's assignment to be the fetched exam.  Then I refetch the
Exam from the database and try to access the parameters of the Exam, and
get the fault exception.  Specifically, the AssignmentParameters can't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrus Adamchik | 2 Jul 2006 16:54
Favicon

Re: SQLTemplate causing exception with Frontbase

Hi Jonathan,

You will need a driver newer that 2.5.2. There were some issues in  
2.5.2 that we found when implementing Cayenne FrontBase adapter.  
Needless to say FrontBase folks fixed them immediately. So please  
upgrade the driver.

Andrus

On Jun 30, 2006, at 6:06 PM, Jonathan Bélisle wrote:

> Hi,
>
> I'm trying to use SQLTemplate with Frontbase but it's giving me an  
> exception when i try to run
> the simpliest queries.
>
> Event select * from XXX won't work.
>
> It always give me a NullPointerException on  
> com.frontbase.jdbc.FBJStatement.getUpdateCount
> in SQLTemplateAction.execute
>
> Caused by: java.lang.NullPointerException
> 	at com.frontbase.jdbc.FBJStatement.getUpdateCount 
> (FBJStatement.java:342)
> 	at org.objectstyle.cayenne.access.jdbc.SQLTemplateAction.execute 
> (SQLTemplateAction.java:210)
> 	at  
> org.objectstyle.cayenne.access.jdbc.SQLTemplateAction.performAction
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Bélisle | 3 Jul 2006 00:57
Picon
Favicon

Re: SQLTemplate causing exception with Frontbase

Thanks Andrus,

Do you know where can i get a driver newer than 2.5.2 ?
The only version available for download on Frontbase web site is 2.5.2.

Jonathan.

>Hi Jonathan,

>You will need a driver newer that 2.5.2. There were some issues in
>2.5.2 that we found when implementing Cayenne FrontBase adapter.
>Needless to say FrontBase folks fixed them immediately. So please
>upgrade the driver.
>
>Andrus
>
>On Jun 30, 2006, at 6:06 PM, Jonathan Bélisle wrote:

>Hi,
>
>I'm trying to use SQLTemplate with Frontbase but it's giving me an
>exception when i try to run
>the simpliest queries.
>
>Event select * from XXX won't work.
>
>It always give me a NullPointerException on
>com.frontbase.jdbc.FBJStatement.getUpdateCount
>in SQLTemplateAction.execute
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Andrus Adamchik | 3 Jul 2006 11:27
Favicon

Re: SQLTemplate causing exception with Frontbase

You may want to contact FrontBase folks on that - their site may have  
outdated info. Also I'll send you my driver jar off the list.

Andrus

On Jul 2, 2006, at 11:57 PM, Jonathan Bélisle wrote:

> Thanks Andrus,
>
> Do you know where can i get a driver newer than 2.5.2 ?
> The only version available for download on Frontbase web site is  
> 2.5.2.
>
> Jonathan.
>
>> Hi Jonathan,
>
>> You will need a driver newer that 2.5.2. There were some issues in
>> 2.5.2 that we found when implementing Cayenne FrontBase adapter.
>> Needless to say FrontBase folks fixed them immediately. So please
>> upgrade the driver.
>>
>> Andrus
>>
>> On Jun 30, 2006, at 6:06 PM, Jonathan Bélisle wrote:
>
>> Hi,
>>
>> I'm trying to use SQLTemplate with Frontbase but it's giving me an
>> exception when i try to run
(Continue reading)

Permalink | Reply | 501 comments |
headers
Marcin Skladaniec | 4 Jul 2006 06:05
Picon

concurrent modification exception (cayenne 3.0 branch, remote persistence)

Hi everyone !

I have this mysterious problem: I'm committing a dozen different records in
one go (payments, payer, invoices, accounts etc). Right after the commit
(when state of some records changes to PersistentState.COMMITED) I create
and commit some extra records and than I commit those new records again
(separate context, all happening on server). All nice. All records saved. No
problem. Than right after after the persistent state is changed I get
"concurrent modification exception", and context on client is returning this
exception, trying to revert changes (but there is nothing in the context)
etc. If I don't restart the application, just create a new context and
repeat the whole process again it works. I though "strange" and I started to
debug the problem.
First I wrote a piece of code which steps thru all records in the context
and prints their attributes and relationships just before the commit to see
what is actually commited, and ... everything works without throwing any
exception.
Than I looked at cayenne code to find what can be causing the concurrent
modification exception. My suspect is call to clear() in graphCommited() in
ObjectContextStateLog, but why ? What I'm I doing wrong so the first time it
fails only for the first time, and only if some objects are not faulted ? I
don't know which objects are actually causing this problem, because if I try
to debug them on client I have to fault them, and this is preventing
exception, and on server I have no real hook to see what is going to be
committed.

Marcin

PS. I'm subscribed to the list, but I had to sent this email from different
account.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrus Adamchik | 4 Jul 2006 21:44
Favicon

Remote Object Persistence Tutorial

I just finished a Remote Object Persistence tutorial. Check it out:

http://objectstyle.org/confluence/x/xgE

Tutorial sources are available here:

http://svn.apache.org/repos/asf/incubator/cayenne/main/trunk/cayenne/ 
tutorials/quick-start-rop/

Power users of this feature (folks like Marcin) won't find anything  
new there, still the feedback is appreciated. And hopefully it should  
be a good starting point for others who are still exploring ROP.

Andrus
Permalink | Reply | 0 comments |
headers
Tomi NA | 5 Jul 2006 17:46
Picon

remote object persistence - client classes

It just occured to me that cayenne remote object persistence might be
the key to a level of interoperability that I need in a very, very
heterogenous environent (i.e. my office) where people use Java, .net
and php, depending on the project, programmer and legacy code.
Is there any special reason not to have a number of templates, each
generating client code for a specific language, so that both Java
programmers and .net programmers could use the same
jetty/tomcat/whatever powered web service as a nice wrapper arround
the database?
Forgive me if I sound so 1999, but there still exist people like me
who have never written a WS so I have to ask. :)

t.n.a.
Permalink | Reply | 5 comments |
headers
Andrus Adamchik | 5 Jul 2006 18:20
Favicon

Re: remote object persistence - client classes

Actually clients written in other languages is one area that has a  
huge potential. And this is something I'd really like to explore.

Current transport layer (Hessian) has support in many other  
languages, also a standard WS interface is being developed as a  
Summer of Code project. All this works already. Still what's lacking  
is an implementation of a client context in anything but Java. This  
is the biggest challenge.

So if there is an interest in the community to write clients in .NET,  
PHP, Ruby, Python, (or maybe JavaScript/AJAX???), etc., let's do it.  
A full implementation would have to mirror "cayenne-client- 
nodeps.jar", but it can start small, by providing only query API, and  
then grow to support relationships and updates.

Thoughts? Comments? Volunteers? ;-)

Andrus

On Jul 5, 2006, at 11:46 AM, Tomi NA wrote:

> It just occured to me that cayenne remote object persistence might be
> the key to a level of interoperability that I need in a very, very
> heterogenous environent (i.e. my office) where people use Java, .net
> and php, depending on the project, programmer and legacy code.
> Is there any special reason not to have a number of templates, each
> generating client code for a specific language, so that both Java
> programmers and .net programmers could use the same
> jetty/tomcat/whatever powered web service as a nice wrapper arround
> the database?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tomi NA | 5 Jul 2006 20:15
Picon

Re: remote object persistence - client classes

On 7/5/06, Andrus Adamchik <andrus <at> objectstyle.org> wrote:
> Actually clients written in other languages is one area that has a
> huge potential. And this is something I'd really like to explore.
>
> Current transport layer (Hessian) has support in many other
> languages, also a standard WS interface is being developed as a
> Summer of Code project. All this works already. Still what's lacking
> is an implementation of a client context in anything but Java. This
> is the biggest challenge.

Well, acording to my limited understanding of the framework, the misc.
client lib implementations would be completely free of the
database-specific code and the templates to generate client classes
should be fairly easy to write...so that leaves the context,
expression manipulation, query manipulation etc. There's some work to
be done there, but it might make cayenne very interesting to a whole
new audience:
"Step 1: Welcome, to the new project wizzard. Please choose your
language: Java/C#/php/Ruby/Python/Perl/whatever."
"Step 2: tell me where your database is and I'll set up the servlet
container and all cayenne-related files so that you can gat your hands
on the db data..."
"Step 3: go!"

...or something along these lines. :)

> So if there is an interest in the community to write clients in .NET,
> PHP, Ruby, Python, (or maybe JavaScript/AJAX???), etc., let's do it.
> A full implementation would have to mirror "cayenne-client-
> nodeps.jar", but it can start small, by providing only query API, and
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrus Adamchik | 5 Jul 2006 20:52
Favicon

Re: remote object persistence - client classes

Remote calls are done via a RemoteService interface (all low-level  
details are handled by Hessian).

public interface RemoteService extends Remote {
     RemoteSession establishSession() throws RemoteException;
     RemoteSession establishSharedSession(String name) throws  
RemoteException;
     Object processMessage(ClientMessage message) throws  
RemoteException, Throwable;
}

The interesting part is "processMessage(ClientMessage)" - essentially  
all communications (including queries and updates) are done using a  
set of ClientMessages. The simplest message would be a QueryMessage  
that holds a NamedQuery. This is probably the place to start.

To estimate the level of effort ... with my current knowledge of the  
framework it would probably take me 2-5 hours to rewrite a very basic  
context-less query client in Java . There may be language-specific  
caveats of course. And a learning curve...

Andrus

On Jul 5, 2006, at 2:15 PM, Tomi NA wrote:

> On 7/5/06, Andrus Adamchik <andrus <at> objectstyle.org> wrote:
>> Actually clients written in other languages is one area that has a
>> huge potential. And this is something I'd really like to explore.
>>
>> Current transport layer (Hessian) has support in many other
(Continue reading)

Permalink | Reply | 2 comments |

Gmane