Invalidating cache from external process?
Hi, I have an web application that serves html pages from a databases. That database is manipulated from a perl program that runs from within a proftpd ftp server. As a result, users can upload their html pages via ftp and the web application displays them. I want to cache the page queries in the web application but have not found a good way to invalidate a certain page in the cache once a user uploads a modified version of it. I use: - Tomcat on Linux - Tapestry 5 - Cayenne 3 - Mysql 5 - Custom mod_exec perl script in proftpd What is the best approach here? /Andreas Pardeike
Re: Can't perform lookup. There is more than one ObjEntity mapped to class
Hi Hans, This may be a genuine error (i.e. you do have two entities that are mapped to the same Java class). Although the fact that it goes away in 3.0 makes me wonder if there is a bug in 2.0.4 EntityResolver. In 3.0 it is much more robust to various cross-ClassLoader and arbitrary naming issues. So check that only one entity is mapped to cl.mydomain.User class, and we'll go from there. Thanks, Andrus On May 3, 2008, at 5:01 PM, Hans Poo wrote: Hi, I'm getting the next error (using cayenne 2.04): Can't perform lookup. There is more than one ObjEntity mapped to class cl.mydomain.User. The model was created with the cayenne 2.04 modeler, and that is the tool i'am using for maintenance. Moreover i've checked the model manually, and the class isn't double mapped. Can anyone give me some help ? I've tried using 3.0 libraries, and the error don't show up. -- The problem is that i'am force to use 2.04 and can't move to 3.0 -- Atte Hans Open WebMail Project (http://openwebmail.org)
Re: Invalidating cache from external process?
for java-to-java invalidation I successfully used OSCache with JGroups. For non-java apps that change the data there are a few options: 1. A private URL in a webapp that a script can access that would cause cache invalidation 2. A timer local to the app that checks a special table in DB that is populated by the script on data changes. 3. A timer running in a remote Java app that checks a DB table, and then notifies another app with JGroups. 4. etc. Andrus On May 5, 2008, at 11:21 AM, Andreas Pardeike wrote: Hi, I have an web application that serves html pages from a databases. That database is manipulated from a perl program that runs from within a proftpd ftp server. As a result, users can upload their html pages via ftp and the web application displays them. I want to cache the page queries in the web application but have not found a good way to invalidate a certain page in the cache once a user uploads a modified version of it. I use: - Tomcat on Linux - Tapestry 5 - Cayenne 3 - Mysql 5 - Custom mod_exec perl script in proftpd What is the best approach here? /Andreas Pardeike
Re: Can't perform lookup. There is more than one ObjEntity mapped to class
Umm, sorry you already said that you don't have doubly mapped class... So what environment are you using for deployment? I am wondering if there is some special ClassLoader setup involved. Andrus On May 5, 2008, at 11:28 AM, Andrus Adamchik wrote: Hi Hans, This may be a genuine error (i.e. you do have two entities that are mapped to the same Java class). Although the fact that it goes away in 3.0 makes me wonder if there is a bug in 2.0.4 EntityResolver. In 3.0 it is much more robust to various cross-ClassLoader and arbitrary naming issues. So check that only one entity is mapped to cl.mydomain.User class, and we'll go from there. Thanks, Andrus On May 3, 2008, at 5:01 PM, Hans Poo wrote: Hi, I'm getting the next error (using cayenne 2.04): Can't perform lookup. There is more than one ObjEntity mapped to class cl.mydomain.User. The model was created with the cayenne 2.04 modeler, and that is the tool i'am using for maintenance. Moreover i've checked the model manually, and the class isn't double mapped. Can anyone give me some help ? I've tried using 3.0 libraries, and the error don't show up. -- The problem is that i'am force to use 2.04 and can't move to 3.0 -- Atte Hans Open WebMail Project (http://openwebmail.org)
Re: Can't perform lookup. There is more than one ObjEntity mapped to class
Hi, I'm using click 1.4 with cayenne 2.04. The whole problem is this: when i begun working with click an cayenne, i installed/copy the libraries manually, and used cayenne 3.0. Latter on, i wanted to use the standard click 1.4 pack (with cayenne 2.04 included), but i was forced to keep cayenne 3.0 libraries and cayenne.xml due to regression problems. Actually i would like to use a fresh click install because logs and the automatic restart of sessions, aren't working as expected. The only way seems to move to cayenne 2.04, or solve manually my worst problem: "I have to restart twice the server on every code modification because unavailability of data context in session restoring". Thank you for your time Hans On Mon, 5 May 2008 11:34:34 +0300, Andrus Adamchik wrote > Umm, sorry you already said that you don't have doubly mapped class... > So what environment are you using for deployment? I am wondering if > there is some special ClassLoader setup involved. > > Andrus > > On May 5, 2008, at 11:28 AM, Andrus Adamchik wrote: > > Hi Hans, > > > > This may be a genuine error (i.e. you do have two entities that are > > mapped to the same Java class). Although the fact that it goes away > > in 3.0 makes me wonder if there is a bug in 2.0.4 EntityResolver. In > > 3.0 it is much more robust to various cross-ClassLoader and > > arbitrary naming issues. So check that only one entity is mapped to > > cl.mydomain.User class, and we'll go from there. > > > > Thanks, > > Andrus > > > > > > On May 3, 2008, at 5:01 PM, Hans Poo wrote: > >> Hi, > >> > >> I'm getting the next error (using cayenne 2.04): > >> > >> Can't perform lookup. There is more than one ObjEntity mapped to > >> class cl.mydomain.User. > >> > >> > >> The model was created with the cayenne 2.04 modeler, and that is > >> the tool i'am using for maintenance. > >> Moreover i've checked the model manually, and the class isn't > >> double mapped. > >> > >> Can anyone give me some help ? > >> > >> I've tried using 3.0 libraries, and the error don't show up. > >> > >> -- The problem is that i'am force to use 2.04 and can't move to 3.0 > >> -- > >> > >> Atte > >> Hans > >> > >> Open WebMail Project (http://openwebmail.org) > >> > >> > > > > -- Open WebMail Project (http://openwebmail.org)
Re: Can't perform lookup. There is more than one ObjEntity mapped to class
Any reason why you can't use Cayenne 3.0 with Click? (I know it is tested with 2.0, but I'd imagine it will happily work with 3.0 as well...or not?) Andrus On May 5, 2008, at 3:36 PM, Hans Poo wrote: Hi, I'm using click 1.4 with cayenne 2.04. The whole problem is this: when i begun working with click an cayenne, i installed/copy the libraries manually, and used cayenne 3.0. Latter on, i wanted to use the standard click 1.4 pack (with cayenne 2.04 included), but i was forced to keep cayenne 3.0 libraries and cayenne.xml due to regression problems. Actually i would like to use a fresh click install because logs and the automatic restart of sessions, aren't working as expected. The only way seems to move to cayenne 2.04, or solve manually my worst problem: "I have to restart twice the server on every code modification because unavailability of data context in session restoring". Thank you for your time Hans On Mon, 5 May 2008 11:34:34 +0300, Andrus Adamchik wrote Umm, sorry you already said that you don't have doubly mapped class... So what environment are you using for deployment? I am wondering if there is some special ClassLoader setup involved. Andrus On May 5, 2008, at 11:28 AM, Andrus Adamchik wrote: Hi Hans, This may be a genuine error (i.e. you do have two entities that are mapped to the same Java class). Although the fact that it goes away in 3.0 makes me wonder if there is a bug in 2.0.4 EntityResolver. In 3.0 it is much more robust to various cross-ClassLoader and arbitrary naming issues. So check that only one entity is mapped to cl.mydomain.User class, and we'll go from there. Thanks, Andrus On May 3, 2008, at 5:01 PM, Hans Poo wrote: Hi, I'm getting the next error (using cayenne 2.04): Can't perform lookup. There is more than one ObjEntity mapped to class cl.mydomain.User. The model was created with the cayenne 2.04 modeler, and that is the tool i'am using for maintenance. Moreover i've checked the model manually, and the class isn't double mapped. Can anyone give me some help ? I've tried using 3.0 libraries, and the error don't show up. -- The problem is that i'am force to use 2.04 and can't move to 3.0 -- Atte Hans Open WebMail Project (http://openwebmail.org) -- Open WebMail Project (http://openwebmail.org)
Re: Can't perform lookup. There is more than one ObjEntity mapped to class
Andrus, I don't think that there were to be problems, we actually are working with click 1.4 and cayenne 3.0, but we are having trouble with the deserialization process. I must aggregate that we aren't very experienced with java, and we would prefer the framework as it comes. Thank you again Hans On Mon, 5 May 2008 15:57:17 +0300, Andrus Adamchik wrote > Any reason why you can't use Cayenne 3.0 with Click? (I know it is > tested with 2.0, but I'd imagine it will happily work with 3.0 as > well...or not?) > > Andrus > > On May 5, 2008, at 3:36 PM, Hans Poo wrote: > > > Hi, > > > > I'm using click 1.4 with cayenne 2.04. > > > > The whole problem is this: when i begun working with click an > > cayenne, i installed/copy the > > libraries manually, and used cayenne 3.0. > > > > Latter on, i wanted to use the standard click 1.4 pack (with cayenne > > 2.04 included), but i was > > forced to keep cayenne 3.0 libraries and cayenne.xml due to > > regression problems. > > > > Actually i would like to use a fresh click install because logs and > > the automatic restart of > > sessions, aren't working as expected. The only way seems to move to > > cayenne 2.04, or solve manually > > my worst problem: "I have to restart twice the server on every code > > modification because > > unavailability of data context in session restoring". > > > > Thank you for your time > > Hans > > > > On Mon, 5 May 2008 11:34:34 +0300, Andrus Adamchik wrote > >> Umm, sorry you already said that you don't have doubly mapped > >> class... > >> So what environment are you using for deployment? I am wondering if > >> there is some special ClassLoader setup involved. > >> > >> Andrus > >> > >> On May 5, 2008, at 11:28 AM, Andrus Adamchik wrote: > >>> Hi Hans, > >>> > >>> This may be a genuine error (i.e. you do have two entities that are > >>> mapped to the same Java class). Although the fact that it goes away > >>> in 3.0 makes me wonder if there is a bug in 2.0.4 EntityResolver. In > >>> 3.0 it is much more robust to various cross-ClassLoader and > >>> arbitrary naming issues. So check that only one entity is mapped to > >>> cl.mydomain.User class, and we'll go from there. > >>> > >>> Thanks, > >>> Andrus > >>> > >>> > >>> On May 3, 2008, at 5:01 PM, Hans Poo wrote: > Hi, > > I'm getting the next error (using cayenne 2.04): > > Can't perform lookup. There is more than one ObjEntity mapped to > class cl.mydomain.User. > > > The model was created with the cayenne 2.04 modeler, and that is > the tool i'am using for maintenance. > Moreover i've checked the model manually, and the class isn't > double mapped. > > Can anyone give me some help ? > > I've tried using 3.0 libraries, and the error don't show up. > > -- The problem is that i'am force to use 2.04 and can't move to > 3.0 > -- > > Atte > Hans > > Open WebMail Project (http://openwebmail.org) > > > >>> > >>> > > > > > > -- > > Open WebMail Project (http://openwebmail.org) > > > > -- Open WebMail Project (http://openwebmail.org)
Re: Query.setRefreshingObjects(boolean)
I don't have any opinion on the actual method involved, but when you remove it, don't have it silently ignore the setting. Either get rid of it completely (so compilation/runtime breaks) or have it continue to function (@deprecated with BIG warnings in the logs). I'd hate to be a developer who misses this in the release notes after upgrading some application, and then tries to figure out why things don't work as expected any more... On 5/3/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > On May 3, 2008, at 6:57 PM, Andrus Adamchik wrote: > > > > a set of queries with a large # of combinations of parameters, but all > searching the same underlying data set that rarely changes > > > > On the other hand, even this example is better served by using query cache. > For a marginal increase in memory use, it should give much better access > speed and refresh manageability. So I am out of examples of why > "setRefreshingObjects(false)" is good, but I'll wait for the comments before > removing it. > > Andrus >
Re: Invalidating cache from external process?
The performance of this may not work for your specific situation, but
my java web application allows for the possibility that some external
process may update the database like this:
I created a table: LAST_EXTERNAL_UPDATE with two fields:
ID
LAST_CHANGED
Any external process changes the LAST_CHANGED timestamp field whenever
something updates.
I created an alternative class to
org.apache.cayenne.conf.BasicServletConfiguration and changed
"getDataContext()" to check for external updates before returning the
dataContext.
try
{
checkForExternalUpdates(dataContext, session);
}
catch (CayenneRuntimeException cayenneRuntimeException)
{
// If it failed, it probably failed during the database
read, so ignore
// REPORT ERROR code here
}
public static void checkForExternalUpdates(DataContext
dataContext, String identityString, HttpSession session)
{
List lastExternalUpdateList = // FETCH YOUR
LAST_EXTERNAL_UPDATE RECORD CODE HERE;
boolean willInvalidate = false;
if (1 != lastExternalUpdateList.size())
{
// database error -- zero or multiple LastExternalUpdate
objects found
// REPORT DATABASE ERROR CODE HERE
}
LastExternalUpdate latestExternalUpdateObject =
(LastExternalUpdate)lastExternalUpdateList.get(0);
if (null == latestExternalUpdateObject)
{
willInvalidate = false;
}
else
{
final Date lastSessionExternalUpdateDate =
(Date)session.getAttribute("lastSessionExternalUpdateDate");
Date latestChangedDate =
latestExternalUpdateObject.getLastChanged();
if (null == latestChangedDate)
{
willInvalidate = false;
}
else if (null == lastSessionExternalUpdateDate)
{
willInvalidate = true;
}
else
{
if (lastSessionExternalUpdateDate.before(latestChangedDate))
{
willInvalidate = true;
}
else
{
willInvalidate = false;
}
}
session.setAttribute("lastSessionExternalUpdateDate",
latestChangedDate);
}
if (willInvalidate)
{
dataContext.invalidateObjects(dataContext.getObjectStore().getObjects());
}
}
Instead of a timer, this method checks every time you request the
session datacontext. And it also invalidates everything if something
changed. You can probably be far more selective than that.
On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
> for java-to-java invalidation I successfully used OSCache with JGroups. For
> non-java apps that change the data there are a few options:
>
> 1. A private URL in a webapp that a script can access that would cause
> cache invalidation
> 2. A timer local to the app that checks a special table in DB that is
> populated by the script on data changes.
> 3. A timer running in a remote Java app that checks a DB table, and then
> notifies another app with JGroups.
> 4. etc.
>
> Andrus
>
>
>
> On May 5, 2008, at 11:21 AM, Andreas Pardeike wrote:
>
>
> > Hi,
> >
> > I have an web application that serves html pages from a databases.
> > That database is manipulated from a perl program that runs from
> > within a proftpd ftp server. As a result, users can upload their
> > html pages via ftp and the web application displays them.
> >
> > I want to cache the page queries in the web application but have
> > not found a good way to invalidate a certain page in the cache once
> > a user uploads a modified version of it.
> >
> > I use:
> >
> > - Tomcat on Linux
> > - Tapestry 5
> > - Cayenne 3
> > - Mysql 5
> > - Custom mod_exec perl script in proftpd
> >
> > What is the best approach here?
> >
> > /Andreas Pardeike
> >
> >
>
>
Re: Query.setRefreshingObjects(boolean)
@deprecated is the way we always do it. That's sort of implied. Andrus On May 5, 2008, at 8:26 PM, Mike Kienenberger wrote: I don't have any opinion on the actual method involved, but when you remove it, don't have it silently ignore the setting. Either get rid of it completely (so compilation/runtime breaks) or have it continue to function (@deprecated with BIG warnings in the logs). I'd hate to be a developer who misses this in the release notes after upgrading some application, and then tries to figure out why things don't work as expected any more... On 5/3/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: On May 3, 2008, at 6:57 PM, Andrus Adamchik wrote: a set of queries with a large # of combinations of parameters, but all searching the same underlying data set that rarely changes On the other hand, even this example is better served by using query cache. For a marginal increase in memory use, it should give much better access speed and refresh manageability. So I am out of examples of why "setRefreshingObjects(false)" is good, but I'll wait for the comments before removing it. Andrus
Re: Query.setRefreshingObjects(boolean)
Maybe I'm simply misunderstanding what you meant by "actually ignoring it in runtime". To me, that sounded like you were going to change the behavior rather than just mark the method as @deprecated. On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > @deprecated is the way we always do it. That's sort of implied. > > Andrus > > > On May 5, 2008, at 8:26 PM, Mike Kienenberger wrote: > > > > I don't have any opinion on the actual method involved, but when you > > remove it, don't have it silently ignore the setting. Either get rid > > of it completely (so compilation/runtime breaks) or have it continue > > to function (@deprecated with BIG warnings in the logs). > > > > I'd hate to be a developer who misses this in the release notes after > > upgrading some application, and then tries to figure out why things > > don't work as expected any more... > > > > On 5/3/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > > > > > > > On May 3, 2008, at 6:57 PM, Andrus Adamchik wrote: > > > > > > > > > > > > > a set of queries with a large # of combinations of parameters, but all > > > > > > > searching the same underlying data set that rarely changes > > > > > > > > > > > > > > > > > On the other hand, even this example is better served by using query > cache. > > > For a marginal increase in memory use, it should give much better access > > > speed and refresh manageability. So I am out of examples of why > > > "setRefreshingObjects(false)" is good, but I'll wait for the comments > before > > > removing it. > > > > > > Andrus > > > > > > > > > > > >
Re: Query.setRefreshingObjects(boolean)
I guess my problem is that to me @deprecate means "it still works like it used to, but it won't work in a future version and it's time for you to change your code", but that's not what's going to happen here. That's why if we're not really @deprecating it but crippling it, then I'd recommend removing it. Giving end-users the false-hope that things are working as usual isn't very nice. You know the details of this particular situation better than I do, though. If you don't think silently doing nothing will affect expected program behavior, go for it. On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote: > > > > To me, that sounded like you were going to change the behavior rather > > than just mark the method as @deprecated. > > > > I was planning to do both. Although we may decide to be gentle about it and > deprecate the method, but preserve the functionality (which will put a bit > of extra maintenance burden on us). > > I am leaning towards the first option (deprecate and stop invoking), > especially since the nature of the change results in enhanced data > consistency, so there won't be any unpleasant surprises. > > Andrus > >
Re: Query.setRefreshingObjects(boolean)
On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote: To me, that sounded like you were going to change the behavior rather than just mark the method as @deprecated. I was planning to do both. Although we may decide to be gentle about it and deprecate the method, but preserve the functionality (which will put a bit of extra maintenance burden on us). I am leaning towards the first option (deprecate and stop invoking), especially since the nature of the change results in enhanced data consistency, so there won't be any unpleasant surprises. Andrus
Re: Query.setRefreshingObjects(boolean)
I'd like to second the opinion that deprecated still works (until removed), but is discouraged from use. I believe that is what Andrus intends, though, given previous API changes. On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > I guess my problem is that to me @deprecate means "it still works like > it used to, but it won't work in a future version and it's time for > you to change your code", but that's not what's going to happen here. > > That's why if we're not really @deprecating it but crippling it, then > I'd recommend removing it. Giving end-users the false-hope that > things are working as usual isn't very nice. > > You know the details of this particular situation better than I do, > though. If you don't think silently doing nothing will affect > expected program behavior, go for it. > > > > On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > > > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote: > > > > > > > To me, that sounded like you were going to change the behavior rather > > > than just mark the method as @deprecated. > > > > > > > I was planning to do both. Although we may decide to be gentle about it > and > > deprecate the method, but preserve the functionality (which will put a bit > > of extra maintenance burden on us). > > > > I am leaning towards the first option (deprecate and stop invoking), > > especially since the nature of the change results in enhanced data > > consistency, so there won't be any unpleasant surprises. > > > > Andrus > > > > >
Re: Query.setRefreshingObjects(boolean)
Actually I was going to do the opposite, but since we've set the backwards compatibility bar for ourselves pretty high in the past, I guess I am persuaded to go with deprecated-but-don't-cripple approach. I guess that means also putting a deprecation note in the Modeler next to refresh checkbox. Andrus On May 5, 2008, at 11:36 PM, Michael Gentry wrote: I'd like to second the opinion that deprecated still works (until removed), but is discouraged from use. I believe that is what Andrus intends, though, given previous API changes. On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote: I guess my problem is that to me @deprecate means "it still works like it used to, but it won't work in a future version and it's time for you to change your code", but that's not what's going to happen here. That's why if we're not really @deprecating it but crippling it, then I'd recommend removing it. Giving end-users the false-hope that things are working as usual isn't very nice. You know the details of this particular situation better than I do, though. If you don't think silently doing nothing will affect expected program behavior, go for it. On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote: To me, that sounded like you were going to change the behavior rather than just mark the method as @deprecated. I was planning to do both. Although we may decide to be gentle about it and deprecate the method, but preserve the functionality (which will put a bit of extra maintenance burden on us). I am leaning towards the first option (deprecate and stop invoking), especially since the nature of the change results in enhanced data consistency, so there won't be any unpleasant surprises. Andrus
Re: Custom configuration class ignored in 3.0 snapshot
Andrus,
That fixed it. Thanks for the quick response!
Brian
--- Andrus Adamchik <[EMAIL PROTECTED]> wrote:
> I was looking for any clues in the code, nothing concrete... And I
> found it. The recent fix to CAY-785 deprecated and stopped calling
> "Configuration.getDataSourceFactory()" replacing it with
> "Configuration.getDataSourceFactory(String)". So you need to override
> the new method. Also I checked in a fix that restores backwards
> compatibility. It should be available from the Hudson CI server soon
> (build #109 or newer).
>
> Andrus
>
>
> On May 3, 2008, at 3:21 AM, Brian Nelson wrote:
>
> > Andrus,
> >
> > I'm not sure exactly how you want the code sample. If you need me to
> > provide a self contained app
> > I can do that. For now I'll just copy the code from my app so you
> > can take a look at it. I have a
> > static method that configures my custom DataSourceFactory. The call
> > to DbUtils.openDb succeeds,
> > but the getDataSourceFactory method in CompanyConfiguration is never
> > called.
> >
> > public class DbUtils {
> > private static DataContext globalContext;
> > private static DataContext estimateContext;
> > private static DataContext roomContext;
> > private static DataContext assemblyContext;
> > private static DataContext partsContext;
> >
> >public static void openDb(String pathToDb) throws Exception {
> > try {
> > CompanyDataSourceFactory.setDbPath(pathToDb);
> >
> > Configuration
> > .initializeSharedConfiguration(CompanyConfiguration.class);
> > Configuration config =
> > Configuration.getSharedConfiguration();
> > DataDomain domain = config.getDomain();
> >
> > globalContext =
> > DataContext.createDataContext(domain.getName());
> > estimateContext =
> > DataContext.createDataContext(domain.getName());
> > roomContext =
> > DataContext.createDataContext(domain.getName());
> > assemblyContext =
> > DataContext.createDataContext(domain.getName());
> > partsContext =
> > DataContext.createDataContext(domain.getName());
> > } catch (Exception e) {
> > throw new Exception("Unable to initialize database!",
> > e);
> > }
> > }
> > }
> >
> > public class CompanyConfiguration extends DefaultConfiguration {
> >
> > private static CompanyDataSourceFactory factory = new
> > CompanyDataSourceFactory();
> >
> > @Override
> > public DataSourceFactory getDataSourceFactory() {
> > return factory;
> > }
> >
> > }
> >
> > public class CompanyDataSourceFactory implements DataSourceFactory {
> >
> > private static DataSource ds = null;
> > private static String dbPath = "Companies/db";
> >
> > public static void setDbPath(String val) {
> > dbPath = val;
> > }
> >
> > @Override
> > public DataSource getDataSource(String arg0) throws Exception {
> > if(dbPath.startsWith("server")) {
> > // server:host
> > ClientDataSource40 tmpDS = new ClientDataSource40();
> > String[] sArray = dbPath.split(":");
> > tmpDS.setServerName(sArray[1]);
> > tmpDS.setDatabaseName("db");
> > tmpDS.setUser("user");
> > tmpDS.setPassword("pass");
> > ds = tmpDS;
> > } else {
> > EmbeddedDataSource40 tmpDS = new EmbeddedDataSource40();
> > tmpDS.setDatabaseName(dbPath);
> > tmpDS.setUser("user");
> > tmpDS.setPassword("db");
> > ds = tmpDS;
> > }
> >
> >
> >
> > return ds;
> > }
> >
> > @Override
> > public void initializeWithParentConfiguration(Configuration arg0) {
> >
> > }
> >
> > }
> >
> > Hopefully that's enough. If not let me know what I should provide.
> >
> > Thanks for your help!
> >
> > Brian
> >
> > --- Andrus Adamchik <[EMAIL PROTECTED]> wrote:
> >
> >> Strange. That should still work the same. The only change to
> >> Configuration since M3 was related to the DataSourceFactory handling
> >> (CAY-785)... Do you have a code example that demonstrates the
> >> problem?
> >>
> >> Thanks,
> >> Andrus
> >>
> >>
> >> On May 1, 2008, at 10:29 PM, Brian Nelson wrote:
> >>> I've been using a custom subclass of DefaultConfiguration to
> >>> customize my database connection.
> >>> This works great with 3.0M3. However, today I upgraded to the
> >>> snapshot build and it seems to be
> >>> ignoring the custom configuration class I pass into the
> >>> Configuration.initializeSharedConfiguration method. Has the way
> >>> custom configurations work
> >>> ch
Re: Query.setRefreshingObjects(boolean)
Just to reiterate, I see no problem with axing it entirely. I don't think we have to nicely deprecate everything since we're now in 3.0 and it's marked unstable. However, we should make the need for change obvious. I don't see much benefit to providing a binary-compatible method API that does nothing. As an end-user, I want to see things either work as they always worked, or be given a clear unavoidable indication that work is required on my part to fix it. Another possibility is to @deprecate the method and have it unconditionally throw a RuntimeException telling the developer to rewrite using query cache options. On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > Actually I was going to do the opposite, but since we've set the backwards > compatibility bar for ourselves pretty high in the past, I guess I am > persuaded to go with deprecated-but-don't-cripple approach. I guess that > means also putting a deprecation note in the Modeler next to refresh > checkbox. > > Andrus > > > On May 5, 2008, at 11:36 PM, Michael Gentry wrote: > > > > I'd like to second the opinion that deprecated still works (until > > removed), but is discouraged from use. I believe that is what Andrus > > intends, though, given previous API changes. > > > > On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger <[EMAIL PROTECTED]> > wrote: > > > > > I guess my problem is that to me @deprecate means "it still works like > > > it used to, but it won't work in a future version and it's time for > > > you to change your code", but that's not what's going to happen here. > > > > > > That's why if we're not really @deprecating it but crippling it, then > > > I'd recommend removing it. Giving end-users the false-hope that > > > things are working as usual isn't very nice. > > > > > > You know the details of this particular situation better than I do, > > > though. If you don't think silently doing nothing will affect > > > expected program behavior, go for it. > > > > > > > > > > > > On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote: > > > > > > > > > > > > > > > > > To me, that sounded like you were going to change the behavior > rather > > > > > than just mark the method as @deprecated. > > > > > > > > > > > > > > > > > > I was planning to do both. Although we may decide to be gentle about > it and > > > > deprecate the method, but preserve the functionality (which will put a > bit > > > > of extra maintenance burden on us). > > > > > > > > I am leaning towards the first option (deprecate and stop invoking), > > > > especially since the nature of the change results in enhanced data > > > > consistency, so there won't be any unpleasant surprises. > > > > > > > > Andrus > > > > > > > > > > > > > > > > > > > > > > > >
RE: Specifying PK when creating a new object in DB generated PK mode
I was looking through my old emails, and I realized that I still haven't found a resolution to this. Andrus vaguely mentioned that there might be a good reason why you aren't allowed to, but I wasn't able to find that reason. So, to recap, here's my scenario: I am normalizing the schema for a request ticket database. I wrote an importer using Cayenne, but I wasn't able to determine how to specify the PK for an object when that type is set to have the PK assigned by the database. The PK is not meaningful (in that its value has no inherent meaning), but it is used as the unique token to identify each REQUEST - after all, it is the PK - and I therefore must keep this value consistent from one schema to the next. I need to have the DB generate PKs for the production code when creating new requests to avoid PK collision, as we have two replicated MASTER servers, one for each country we are located in; the anti-collision strategy is to have PKs generated by the database where PK MOD 10 is a different value on each MASTER.
RE: Query.setRefreshingObjects(boolean)
> I don't see > much benefit to providing a binary-compatible method API that does > nothing. ... > Another possibility is to @deprecate the method and have it > unconditionally throw a RuntimeException telling the developer to > rewrite using query cache options. Adding a Throws clause to the method would change its signature, thereby breaking the binary compatibility of the method. It's a good idea, but it won't solve that problem. :) Regards, Scott -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Monday, May 05, 2008 5:01 PM To: user@cayenne.apache.org Subject: Re: Query.setRefreshingObjects(boolean) Just to reiterate, I see no problem with axing it entirely. I don't think we have to nicely deprecate everything since we're now in 3.0 and it's marked unstable. However, we should make the need for change obvious. I don't see much benefit to providing a binary-compatible method API that does nothing. As an end-user, I want to see things either work as they always worked, or be given a clear unavoidable indication that work is required on my part to fix it. Another possibility is to @deprecate the method and have it unconditionally throw a RuntimeException telling the developer to rewrite using query cache options. On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > Actually I was going to do the opposite, but since we've set the backwards > compatibility bar for ourselves pretty high in the past, I guess I am > persuaded to go with deprecated-but-don't-cripple approach. I guess that > means also putting a deprecation note in the Modeler next to refresh > checkbox. > > Andrus > > > On May 5, 2008, at 11:36 PM, Michael Gentry wrote: > > > > I'd like to second the opinion that deprecated still works (until > > removed), but is discouraged from use. I believe that is what Andrus > > intends, though, given previous API changes. > > > > On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger <[EMAIL PROTECTED]> > wrote: > > > > > I guess my problem is that to me @deprecate means "it still works like > > > it used to, but it won't work in a future version and it's time for > > > you to change your code", but that's not what's going to happen here. > > > > > > That's why if we're not really @deprecating it but crippling it, then > > > I'd recommend removing it. Giving end-users the false-hope that > > > things are working as usual isn't very nice. > > > > > > You know the details of this particular situation better than I do, > > > though. If you don't think silently doing nothing will affect > > > expected program behavior, go for it. > > > > > > > > > > > > On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote: > > > > > > > > > > > > > > > > > To me, that sounded like you were going to change the behavior > rather > > > > > than just mark the method as @deprecated. > > > > > > > > > > > > > > > > > > I was planning to do both. Although we may decide to be gentle about > it and > > > > deprecate the method, but preserve the functionality (which will put a > bit > > > > of extra maintenance burden on us). > > > > > > > > I am leaning towards the first option (deprecate and stop invoking), > > > > especially since the nature of the change results in enhanced data > > > > consistency, so there won't be any unpleasant surprises. > > > > > > > > Andrus > > > > > > > > > > > > > > > > > > > > > > > >
Re: Query.setRefreshingObjects(boolean)
You don't have to declare the throw clause if it's a RuntimeException. The method signature doesn't have to change. On 5/5/08, Scott Anderson <[EMAIL PROTECTED]> wrote: > > I don't see > > much benefit to providing a binary-compatible method API that does > > nothing. > > ... > > > Another possibility is to @deprecate the method and have it > > unconditionally throw a RuntimeException telling the developer to > > rewrite using query cache options. > > > Adding a Throws clause to the method would change its signature, thereby > breaking the binary compatibility of the method. It's a good idea, but > it won't solve that problem. :) > > Regards, > > Scott > > > -Original Message- > From: Mike Kienenberger [mailto:[EMAIL PROTECTED] > Sent: Monday, May 05, 2008 5:01 PM > To: user@cayenne.apache.org > Subject: Re: Query.setRefreshingObjects(boolean) > > Just to reiterate, I see no problem with axing it entirely. I don't > think we have to nicely deprecate everything since we're now in 3.0 > and it's marked unstable. > > However, we should make the need for change obvious. I don't see > much benefit to providing a binary-compatible method API that does > nothing. As an end-user, I want to see things either work as they > always worked, or be given a clear unavoidable indication that work is > required on my part to fix it. > > Another possibility is to @deprecate the method and have it > unconditionally throw a RuntimeException telling the developer to > rewrite using query cache options. > > On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > Actually I was going to do the opposite, but since we've set the > backwards > > compatibility bar for ourselves pretty high in the past, I guess I am > > persuaded to go with deprecated-but-don't-cripple approach. I guess > that > > means also putting a deprecation note in the Modeler next to refresh > > checkbox. > > > > Andrus > > > > > > On May 5, 2008, at 11:36 PM, Michael Gentry wrote: > > > > > > > I'd like to second the opinion that deprecated still works (until > > > removed), but is discouraged from use. I believe that is what > Andrus > > > intends, though, given previous API changes. > > > > > > On Mon, May 5, 2008 at 4:02 PM, Mike Kienenberger > <[EMAIL PROTECTED]> > > wrote: > > > > > > > I guess my problem is that to me @deprecate means "it still works > like > > > > it used to, but it won't work in a future version and it's time > for > > > > you to change your code", but that's not what's going to happen > here. > > > > > > > > That's why if we're not really @deprecating it but crippling it, > then > > > > I'd recommend removing it. Giving end-users the false-hope that > > > > things are working as usual isn't very nice. > > > > > > > > You know the details of this particular situation better than I > do, > > > > though. If you don't think silently doing nothing will affect > > > > expected program behavior, go for it. > > > > > > > > > > > > > > > > On 5/5/08, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On May 5, 2008, at 10:39 PM, Mike Kienenberger wrote: > > > > > > > > > > > > > > > > > > > > > To me, that sounded like you were going to change the behavior > > rather > > > > > > than just mark the method as @deprecated. > > > > > > > > > > > > > > > > > > > > > > I was planning to do both. Although we may decide to be gentle > about > > it and > > > > > deprecate the method, but preserve the functionality (which will > put a > > bit > > > > > of extra maintenance burden on us). > > > > > > > > > > I am leaning towards the first option (deprecate and stop > invoking), > > > > > especially since the nature of the change results in enhanced > data > > > > > consistency, so there won't be any unpleasant surprises. > > > > > > > > > > Andrus > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: OracleSelectTranslator can not access OracleStatementWrapper
Hi there, great, thanks. Our application runs with the 10.x driver. Oracle has probably changed some interfaces in the 11.x driver Matthias On 05/05/2008, at 4:54 PM, Andrus Adamchik wrote: Never used the 11.x driver. Let me try running the unit tests with it. Andrus On May 5, 2008, at 5:18 AM, Lachlan Deck wrote: Hi there, We're testing the use of Oracle Database 10g (actually the Express Edition for testing) via the JDBC Thin driver (oracle.driver.OracleDriver). e.g., uri: jdbc:oracle:thin:@host:port:db We've downloaded the driver jar ojdbc5 11.1.0.6 here: http://www.oracle.com/technology/tech/java/sqlj_jdbc/index.html However, we're seeing the below exception when attempting to create a statement. It's seemingly not surprising as the OracleStatementWrapper is not public. Does anyone have any suggestions or work-a-rounds for this? Thanks with regards, -- Lachlan Deck Caused by: java.lang.IllegalAccessException: Class org.apache.cayenne.dba.oracle.OracleSelectTranslator can not access a member of class oracle.jdbc.driver.OracleStatementWrapper with modifiers "public" [java] at sun.reflect.Reflection.ensureMemberAccess (Reflection.java:65) [java] at java.lang.reflect.Method.invoke(Method.java:578) [java] at org.apache.cayenne.dba.oracle.OracleSelectTranslator.createStatement( OracleSelectTranslator.java:132) [java] at org.apache.cayenne.access.jdbc.SelectAction.performAction (SelectAction.java:72) [java] at org.apache.cayenne.access.DataNodeQueryAction.runQuery (DataNodeQueryAction.java:58) [java] at org.apache.cayenne.access.DataNode.performQueries (DataNode.java:230)
Newbie question about to-many ordered list
Hi All, I recently discovered Cayenne while searching for an alternative for Hibernate. I am very impressed with the easy & intuitive framework Cayenne provides. While porting my current Hibernate app to Cayenne, I did run into an issue which I'd like to seek your help: In Hibernate, the M side of 1-M relationship can be mapped as a list, which means it's ordered. I can specify the list-index column like this: ... and the BID_POSITION is automatically managed by the framework. Is there any 'list index column' equivalent in Cayenne? How can I ask the framework to manage the list index ? or do I have to manage it by myself? Thanks very much!!
Re: Newbie question about to-many ordered list
On 06/05/2008, at 11:30 AM, JGL wrote: Hi All, I recently discovered Cayenne while searching for an alternative for Hibernate. I am very impressed with the easy & intuitive framework Cayenne provides. While porting my current Hibernate app to Cayenne, I did run into an issue which I'd like to seek your help: In Hibernate, the M side of 1-M relationship can be mapped as a list, which means it's ordered. I can specify the list-index column like this: ... and the BID_POSITION is automatically managed by the framework. Is there any 'list index column' equivalent in Cayenne? How can I ask the framework to manage the list index ? or do I have to manage it by myself? Thanks very much!! Well, you can order the results easily enough once you fetch them into a list: http://cayenne.apache.org/doc/using-orderings.html In Cayenne 3 you can also fetch the results into a Map if that helps what you are trying to do. Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
