Re: Multiple clients in single DB
I spoke to soon, it seems that awakeFromInsertion does NOT register
flattened tables being inserted?
I guess I really don't need to store the client for a Flatteren join
table as it can be determined via the relationships. However it seems
odd awakeFromInsertion does not get called even though there is a
"insert" being sent to the DB.
Is there away to know when a flattened table is being inserted?
I have tried both awakeFromInsertion and Chucks
CooperatingEditingContext.objectsToBeInserted() but neither work.
Dave
On 27/04/2007, at 10:47 AM, Dave Elsner wrote:
Excellent, that was the confirmation I was looking for. For now it
works for multiple application instances but eventually I will run
all clients from the single instance. Thanks.
On 27/04/2007, at 6:35 AM, Lachlan Deck wrote:
Hi Dave,
On 26/04/2007, at 11:33 AM, Dave Elsner wrote:
I have an WO5.3 application I want to deploy to five different
clients, all have the same DB (Oracle) schema but different data.
I would like to use a shared database with a new column in each
table "client" that has the client ID. Then override
awakeFromInsertion for all EOEntities to set the client ID
That's what I've done (though it's done generically in a super
class rather than per entity). Something like:
public void awakeFromInsertion( EOEditingContext ec ) {
super.awakeFromInsertion( ec );
if ( ec instanceof MyEditingContext && hasKey( CLIENT_KEY ) ) {
Client currentClient = ( Client )ec.valueForKey( CLIENT_KEY );
if ( hasReverseRelationship )
addObjectToBothSidesOfRelationshipWithKey( currentClient,
CLIENT_KEY );
else
takeValueForKey( currentClient, CLIENT_KEY );
}
}
and also add to the Application constructor a loop that sets an
EOQualifier on each entity in the model limiting objects to the
current client.
Sure that's one way to do it if you're going to be running them as
separate instances. I'm dealing with this within the same instance
(s) by an additional table ClientDomain (Client <-->>
ClientDomain). I've got some cover methods in my Application class
that when needed can find the relevant object for a request. It
stores the result in the userInfo dictionary of the request so
that this only need be fetched once, if at all - seeing as these
objects are pre-fetched in a shared ec.
public Client clientForRequest( WORequest aRequest ) throws
EOObjectNotAvailableException, EOUtilities.MoreThanOneException;
public ClientDomain clientDomainForRequest( WORequest aRequest )
throws EOObjectNotAvailableException;
I'm then (in a base controller/component) able to have cover
methods for these. e.g.,
public Client myClient() {
return myApplication().clientForRequest( context() );
}
and whenever I need to create data, I create an instance of my
subclass of EOEditingContext which is instantiated with an
additional parameter for the ClientDomain, allowing it to localise
as necessary internally and for the above valueForKey to return
the related Client object.
Questions:
* Is this the correct approach to solve this problem? (i.e not
wanting to update X number of identical DB schemas every-time a
change is made, keeping the data in the one location for reporting)
Perhaps the above helps.
* I tried EOEntity.setRestrictingQualifier but that overrides
any single table inheritance setup in the model. Is there away to
merge two EOQualifiers?
When iterating through each entity, do an EOAndQualifier with any
existing restricting qualifier so that you don't blow it away.
with regards,
--
Lachlan Deck
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/delsner%
40uow.edu.au
This email sent to [EMAIL PROTECTED]
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Multiple clients in single DB
Excellent, that was the confirmation I was looking for. For now it
works for multiple application instances but eventually I will run
all clients from the single instance. Thanks.
On 27/04/2007, at 6:35 AM, Lachlan Deck wrote:
Hi Dave,
On 26/04/2007, at 11:33 AM, Dave Elsner wrote:
I have an WO5.3 application I want to deploy to five different
clients, all have the same DB (Oracle) schema but different data.
I would like to use a shared database with a new column in each
table "client" that has the client ID. Then override
awakeFromInsertion for all EOEntities to set the client ID
That's what I've done (though it's done generically in a super
class rather than per entity). Something like:
public void awakeFromInsertion( EOEditingContext ec ) {
super.awakeFromInsertion( ec );
if ( ec instanceof MyEditingContext && hasKey( CLIENT_KEY ) ) {
Client currentClient = ( Client )ec.valueForKey( CLIENT_KEY );
if ( hasReverseRelationship )
addObjectToBothSidesOfRelationshipWithKey( currentClient,
CLIENT_KEY );
else
takeValueForKey( currentClient, CLIENT_KEY );
}
}
and also add to the Application constructor a loop that sets an
EOQualifier on each entity in the model limiting objects to the
current client.
Sure that's one way to do it if you're going to be running them as
separate instances. I'm dealing with this within the same instance
(s) by an additional table ClientDomain (Client <-->>
ClientDomain). I've got some cover methods in my Application class
that when needed can find the relevant object for a request. It
stores the result in the userInfo dictionary of the request so that
this only need be fetched once, if at all - seeing as these objects
are pre-fetched in a shared ec.
public Client clientForRequest( WORequest aRequest ) throws
EOObjectNotAvailableException, EOUtilities.MoreThanOneException;
public ClientDomain clientDomainForRequest( WORequest aRequest )
throws EOObjectNotAvailableException;
I'm then (in a base controller/component) able to have cover
methods for these. e.g.,
public Client myClient() {
return myApplication().clientForRequest( context() );
}
and whenever I need to create data, I create an instance of my
subclass of EOEditingContext which is instantiated with an
additional parameter for the ClientDomain, allowing it to localise
as necessary internally and for the above valueForKey to return the
related Client object.
Questions:
* Is this the correct approach to solve this problem? (i.e not
wanting to update X number of identical DB schemas every-time a
change is made, keeping the data in the one location for reporting)
Perhaps the above helps.
* I tried EOEntity.setRestrictingQualifier but that overrides any
single table inheritance setup in the model. Is there away to
merge two EOQualifiers?
When iterating through each entity, do an EOAndQualifier with any
existing restricting qualifier so that you don't blow it away.
with regards,
--
Lachlan Deck
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: I'm killing my database
On Apr 26, 2007, at 5:01 PM, Scott Winn wrote: On Apr 26, 2007, at 10:41 AM, Chuck Hill wrote: On Apr 26, 2007, at 8:19 AM, Scott Winn wrote: When I have put a lot of data through the Importer previously I had the application crash with a SIGBUS error. I have only seen that happen in three situations (there are probably more, but this will give you a good idea): 1. Bug in JVM 2. Faulty hardware 3. Crash in native code (QT Java in my case) So, it is probably not a bug in your code. On a separate occasion, the app didn't crash, but when I went to log out I got "Internal Server Error has occurred". Looking at the run log showed three null pointer exceptions encountered; trying to dispose the editing context from the look of them (I should have saved those exception messages). Both of these problams happened in previous tests before the DB crash. That does look like a bug in your code. I would suspect your cleanup of the WOLongResponePage. Well that was easy to reproduce. I get three of them when I try to logout. [2007-04-26 11:28:58 PDT] java.lang.NullPointerException at com.webobjects.eocontrol.EOEditingContext._dispose (EOEditingContext.java:1067) at com.webobjects.eocontrol.EOEditingContext.dispose (EOEditingContext.java:1059) at com.webobjects.appserver.WOSession._sleepInContext (WOSession.java:729) at com.webobjects.appserver.WOApplication.saveSessionForContext (WOApplication.java:1514) at com.webobjects.appserver._private.WOComponentRequestHandler._handleReq uest(WOComponentRequestHandler.java:398) at com.webobjects.appserver._private.WOComponentRequestHandler.handleRequ est(WOComponentRequestHandler.java:432) at com.webobjects.appserver.WOApplication.dispatchRequest (WOApplication.java:1306) at com.webobjects.appserver._private.WOWorkerThread.runOnce (WOWorkerThread.java:173) at com.webobjects.appserver._private.WOWorkerThread.run (WOWorkerThread.java:254) at java.lang.Thread.run(Thread.java:613) I was calling dispose() on the default EC just before session ().terminate(). I took that out and it seems to be working fine. Does that explain the issue? Yes, WO calls dispose on this for you. You rarely need to call this yourself. Inside an importer is one place where it can be useful in terms of reclaiming memory. I'm sure both of those incidents should raise warning flags, but I'm not sure what those flags mean. Do they point to the same problem? I found basically no information on SIGBUS errors. I can run everything through from the top and see if I have the same issues, but I think I'll try to get performance boosted a bit first. I will look into batch faulting and disposing the editing context at regular intervals. I should mention that all of this is happening on a WOLongResponse page, so a user can watch the import progress and fix any errors in the source files. That should be fine, but you have to think twice about when you clean up stuff when you start spinning off extra threads. Are there issues with using the default EC in a WOLongResponse or should I define my own EC? Using the default EC will deadlock the session (and your app if it dispatches single threaded). I imagine that would be an issue. :-P You could definitely define your own EC for the long running process. Chuck On Apr 25, 2007, at 5:44 PM, Chuck Hill wrote: On Apr 25, 2007, at 12:03 PM, Scott Winn wrote: Thanks Chuck. I will give it a look. I still don't know what the problem was, but I have updated FrontBase and its plugin (I was a few point releases behind). The release notes for some of those points included delete fixes. I also added EC.undoManager().removeAllActions(). I haven't disposed of the editing context yet, but I may once I have checked the performance results from my most recent run. I put the same data back through the importer and no DB crash this time, That is from the FB update. although things still seemed very slow. More than 1/2 an hour to process about 1 MB of data seem like a bit much. I checked free memory just prior to doing the delete and it never dips below 74%. I have no doubt that it can be optimized more than that. Make sure you have batch faulting configured in the model. Chuck On Apr 24, 2007, at 10:32 PM, Guido Neitzer wrote: On 24.04.2007, at 20:59, Chuck Hill wrote: The first thing I would do is to add this line: recordContext .undoManager().removeAllActions(); The next thing I would do (voodoo or not) is to periodically dispose of recordContext and create a replacement. In the past that was vital. It still is. It helps. Not necessarily for performance but normally for memory usage. I normally do bulk import in batches of up to 500 objects per batch, then save and dispose the editingContext, set it to null and create in new one in the next batch. Also for bulk updating of EOs. That works well f
Re: I'm killing my database
On Apr 26, 2007, at 10:41 AM, Chuck Hill wrote: On Apr 26, 2007, at 8:19 AM, Scott Winn wrote: When I have put a lot of data through the Importer previously I had the application crash with a SIGBUS error. I have only seen that happen in three situations (there are probably more, but this will give you a good idea): 1. Bug in JVM 2. Faulty hardware 3. Crash in native code (QT Java in my case) So, it is probably not a bug in your code. On a separate occasion, the app didn't crash, but when I went to log out I got "Internal Server Error has occurred". Looking at the run log showed three null pointer exceptions encountered; trying to dispose the editing context from the look of them (I should have saved those exception messages). Both of these problams happened in previous tests before the DB crash. That does look like a bug in your code. I would suspect your cleanup of the WOLongResponePage. Well that was easy to reproduce. I get three of them when I try to logout. [2007-04-26 11:28:58 PDT] java.lang.NullPointerException at com.webobjects.eocontrol.EOEditingContext._dispose (EOEditingContext.java:1067) at com.webobjects.eocontrol.EOEditingContext.dispose (EOEditingContext.java:1059) at com.webobjects.appserver.WOSession._sleepInContext(WOSession.java: 729) at com.webobjects.appserver.WOApplication.saveSessionForContext (WOApplication.java:1514) at com.webobjects.appserver._private.WOComponentRequestHandler._handleReque st(WOComponentRequestHandler.java:398) at com.webobjects.appserver._private.WOComponentRequestHandler.handleReques t(WOComponentRequestHandler.java:432) at com.webobjects.appserver.WOApplication.dispatchRequest (WOApplication.java:1306) at com.webobjects.appserver._private.WOWorkerThread.runOnce (WOWorkerThread.java:173) at com.webobjects.appserver._private.WOWorkerThread.run (WOWorkerThread.java:254) at java.lang.Thread.run(Thread.java:613) I was calling dispose() on the default EC just before session ().terminate(). I took that out and it seems to be working fine. Does that explain the issue? I'm sure both of those incidents should raise warning flags, but I'm not sure what those flags mean. Do they point to the same problem? I found basically no information on SIGBUS errors. I can run everything through from the top and see if I have the same issues, but I think I'll try to get performance boosted a bit first. I will look into batch faulting and disposing the editing context at regular intervals. I should mention that all of this is happening on a WOLongResponse page, so a user can watch the import progress and fix any errors in the source files. That should be fine, but you have to think twice about when you clean up stuff when you start spinning off extra threads. Are there issues with using the default EC in a WOLongResponse or should I define my own EC? Thanks again for the assistance, Scott On Apr 25, 2007, at 5:44 PM, Chuck Hill wrote: On Apr 25, 2007, at 12:03 PM, Scott Winn wrote: Thanks Chuck. I will give it a look. I still don't know what the problem was, but I have updated FrontBase and its plugin (I was a few point releases behind). The release notes for some of those points included delete fixes. I also added EC.undoManager().removeAllActions(). I haven't disposed of the editing context yet, but I may once I have checked the performance results from my most recent run. I put the same data back through the importer and no DB crash this time, That is from the FB update. although things still seemed very slow. More than 1/2 an hour to process about 1 MB of data seem like a bit much. I checked free memory just prior to doing the delete and it never dips below 74%. I have no doubt that it can be optimized more than that. Make sure you have batch faulting configured in the model. Chuck On Apr 24, 2007, at 10:32 PM, Guido Neitzer wrote: On 24.04.2007, at 20:59, Chuck Hill wrote: The first thing I would do is to add this line: recordContext .undoManager().removeAllActions(); The next thing I would do (voodoo or not) is to periodically dispose of recordContext and create a replacement. In the past that was vital. It still is. It helps. Not necessarily for performance but normally for memory usage. I normally do bulk import in batches of up to 500 objects per batch, then save and dispose the editingContext, set it to null and create in new one in the next batch. Also for bulk updating of EOs. That works well for my importers. If you need to resolve relationships during import, pre- fetching the relationships can make a huge difference. As as you are deleting, I have a DeletePrefetcher class that may be of use. I originally wrote this as a bug workaround, but it might also make the fetches more efficient. It is part of our GVCEOFExtensions framework that you can get from http:// sourceforge.net/
Re: Snapshot Question
Hi Andrew,
On Apr 26, 2007, at 4:14 PM, Andrew Lindesay wrote:
Hello;
I'm getting an error at...
at ..EODatabaseOperation.rowDiffsForAttributes
(EODatabaseOperation.java:338)
at ..EODatabaseContext.createAdaptorOperationsForDatabaseOperationAtt
ributes(EODatabaseContext.java:5373)
at ..EODatabaseContext.createAdaptorOperationsForDatabaseOperation
(EODatabaseContext.java:5548)
at ..EODatabaseContext.performChanges(EODatabaseContext.java:6365)
at ..EOObjectStoreCoordinator.saveChangesInEditingContext
(EOObjectStoreCoordinator.java:415)
at ..EOEditingContext.saveChanges(EOEditingContext.java:3226)
...which looks a bit like this (entity name changed)...
rowDiffsForAttributes: snapshot in
com.webobjects.eoaccess.EODatabaseOperation
{_dbSnapshot = {};
That is the snapshot that it is complaining about. Notice that it
has _no_ values in it. It is missing a snapshot for this object.
articleBody just happens to be the first attribute it looked for. I
have had this happen several times to me, it was always bad EOF
locking that caused it.
_entity = "MyEntity"; _newRow =
{
...
articleBody = ;
...
};
_object = "{values = {
...
articleBody = ;
...
};
this = "[CBClip (java.lang.Integer)1637467]>"; }";
_globalID = _EOIntegralKeyGlobalID[MyEntity (java.lang.Integer)
1637467]; _databaseOperator = "EODatabaseUpdateOperator";
}
does not contain value for attribute named articleBody with
snapshot key: articleBody
Which is confusing because "articleBody" seems to be there in the
snap. It can't be marshalling its optimistic locking because there
is none on the "articleBody" attribute. It must be looking to see
if there is a change in order to turn that change into adaptor
operations. I'm using...
forgetSnapshotForGlobalID(...)
recordSnapshotForSourceGlobalID(null, gidA, rA.name());
... on EODatabase as discussed some weeks ago here for change
notification.
Are you locking the object store co-ordinator before doing this? EC
locking is not enough here.
I'm pretty sure that I am locking the EODatabaseContext for the
entity appropriately before dropping snapshots. I assume that
"EOObjectStoreCoordinator" must also lock the database context
before "performChanges(...)".
I think you need to lock up at the OSC level, I could be wrong.
It is highly likely that two users of the WOA are trying to edit
the same data at the same time here. Anything I've obviously
forgotten?
That is all that comes to mind at the moment.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Snapshot Question
Hello;
I'm getting an error at...
at ..EODatabaseOperation.rowDiffsForAttributes
(EODatabaseOperation.java:338)
at ..EODatabaseContext.createAdaptorOperationsForDatabaseOperationAttr
ibutes(EODatabaseContext.java:5373)
at ..EODatabaseContext.createAdaptorOperationsForDatabaseOperation
(EODatabaseContext.java:5548)
at ..EODatabaseContext.performChanges(EODatabaseContext.java:6365)
at ..EOObjectStoreCoordinator.saveChangesInEditingContext
(EOObjectStoreCoordinator.java:415)
at ..EOEditingContext.saveChanges(EOEditingContext.java:3226)
...which looks a bit like this (entity name changed)...
rowDiffsForAttributes: snapshot in
com.webobjects.eoaccess.EODatabaseOperation
{_dbSnapshot = {}; _entity = "MyEntity"; _newRow =
{
...
articleBody = ;
...
};
_object = "{values = {
...
articleBody = ;
...
};
this = "[CBClip (java.lang.Integer)1637467]>"; }";
_globalID = _EOIntegralKeyGlobalID[MyEntity (java.lang.Integer)
1637467]; _databaseOperator = "EODatabaseUpdateOperator";
}
does not contain value for attribute named articleBody with
snapshot key: articleBody
Which is confusing because "articleBody" seems to be there in the
snap. It can't be marshalling its optimistic locking because there
is none on the "articleBody" attribute. It must be looking to see if
there is a change in order to turn that change into adaptor
operations. I'm using...
forgetSnapshotForGlobalID(...)
recordSnapshotForSourceGlobalID(null, gidA, rA.name());
... on EODatabase as discussed some weeks ago here for change
notification. I'm pretty sure that I am locking the
EODatabaseContext for the entity appropriately before dropping
snapshots. I assume that "EOObjectStoreCoordinator" must also lock
the database context before "performChanges(...)".
It is highly likely that two users of the WOA are trying to edit the
same data at the same time here. Anything I've obviously forgotten?
cheers.
___
Andrew Lindesay
www.lindesay.co.nz
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Array variables in building a qualifier in EOModeler
Hello, Is there a simple way to build a qualifier in EOModeler such that it is possible to use a variable binding that is an array? So, for example, going beyond the traditional "city = $city", is it possible to bind in the fashion, "city = @cities", and have EOModeler generate the AND/OR SQL statements to include all the items in the "cities" array? Or is the only way to do that within code, programatically? Thanks. ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Multiple clients in single DB
Hi Dave,
On 26/04/2007, at 11:33 AM, Dave Elsner wrote:
I have an WO5.3 application I want to deploy to five different
clients, all have the same DB (Oracle) schema but different data. I
would like to use a shared database with a new column in each table
"client" that has the client ID. Then override awakeFromInsertion
for all EOEntities to set the client ID
That's what I've done (though it's done generically in a super class
rather than per entity). Something like:
public void awakeFromInsertion( EOEditingContext ec ) {
super.awakeFromInsertion( ec );
if ( ec instanceof MyEditingContext && hasKey( CLIENT_KEY ) ) {
Client currentClient = ( Client )ec.valueForKey( CLIENT_KEY );
if ( hasReverseRelationship )
addObjectToBothSidesOfRelationshipWithKey( currentClient,
CLIENT_KEY );
else
takeValueForKey( currentClient, CLIENT_KEY );
}
}
and also add to the Application constructor a loop that sets an
EOQualifier on each entity in the model limiting objects to the
current client.
Sure that's one way to do it if you're going to be running them as
separate instances. I'm dealing with this within the same instance(s)
by an additional table ClientDomain (Client <-->> ClientDomain). I've
got some cover methods in my Application class that when needed can
find the relevant object for a request. It stores the result in the
userInfo dictionary of the request so that this only need be fetched
once, if at all - seeing as these objects are pre-fetched in a shared
ec.
public Client clientForRequest( WORequest aRequest ) throws
EOObjectNotAvailableException, EOUtilities.MoreThanOneException;
public ClientDomain clientDomainForRequest( WORequest aRequest )
throws EOObjectNotAvailableException;
I'm then (in a base controller/component) able to have cover methods
for these. e.g.,
public Client myClient() {
return myApplication().clientForRequest( context() );
}
and whenever I need to create data, I create an instance of my
subclass of EOEditingContext which is instantiated with an additional
parameter for the ClientDomain, allowing it to localise as necessary
internally and for the above valueForKey to return the related Client
object.
Questions:
* Is this the correct approach to solve this problem? (i.e not
wanting to update X number of identical DB schemas every-time a
change is made, keeping the data in the one location for reporting)
Perhaps the above helps.
* I tried EOEntity.setRestrictingQualifier but that overrides any
single table inheritance setup in the model. Is there away to merge
two EOQualifiers?
When iterating through each entity, do an EOAndQualifier with any
existing restricting qualifier so that you don't blow it away.
with regards,
--
Lachlan Deck
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: problem with delete rule (relationship)
no, all seem to be correct... I don't know.. On 26/apr/07, at 19:46, Chuck Hill wrote: No solid idea, but violating EOF commandments can have effects like this. Improper locking can do this too. Chuck On Apr 26, 2007, at 7:59 AM, Amedeo Mantica wrote: Hello, I have two Entities entity Products have these attributes too... imgIconID imgPrindID imgLargeID ... these are foreing keys for may relation with Image entity that have ImageID fileName mimeType fileData etc... any Product have relationship to images is a To One relationship see images, is better than words http://downloads.insigno.net/help/dbimage1.jpg http://downloads.insigno.net/help/dbimage2.jpg http://downloads.insigno.net/help/dbimage3.jpg THE CASCADE RULE WORKS for all relationship: imgPrindID imgLargeID imgSchema imgMedium EXCEPT for imgIconID that is IDENTICALLY configured !!! any suggestion? I have tried to override the validateForDelete in entity Image and setting a breakpoint, semm to be totally skipped...! Thanks Amedeo___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/chill% 40global-village.net This email sent to [EMAIL PROTECTED] -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I'm killing my database
On Apr 26, 2007, at 11:23 AM, Pascal Robert wrote: 3. Crash in native code (QT Java in my case) So I'm not the only who used QT4Java with WebObjects ? ;-) What a miserable disaster that was! -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I'm killing my database
Le 07-04-26 à 13:41, Chuck Hill a écrit : On Apr 26, 2007, at 8:19 AM, Scott Winn wrote: When I have put a lot of data through the Importer previously I had the application crash with a SIGBUS error. I have only seen that happen in three situations (there are probably more, but this will give you a good idea): 1. Bug in JVM 2. Faulty hardware Especially bad RAM. But most time the RAM is the cause, it's a "Bus error" who is throw. 3. Crash in native code (QT Java in my case) So I'm not the only who used QT4Java with WebObjects ? ;-) ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: problem with delete rule (relationship)
No solid idea, but violating EOF commandments can have effects like this. Improper locking can do this too. Chuck On Apr 26, 2007, at 7:59 AM, Amedeo Mantica wrote: Hello, I have two Entities entity Products have these attributes too... imgIconID imgPrindID imgLargeID ... these are foreing keys for may relation with Image entity that have ImageID fileName mimeType fileData etc... any Product have relationship to images is a To One relationship see images, is better than words http://downloads.insigno.net/help/dbimage1.jpg http://downloads.insigno.net/help/dbimage2.jpg http://downloads.insigno.net/help/dbimage3.jpg THE CASCADE RULE WORKS for all relationship: imgPrindID imgLargeID imgSchema imgMedium EXCEPT for imgIconID that is IDENTICALLY configured !!! any suggestion? I have tried to override the validateForDelete in entity Image and setting a breakpoint, semm to be totally skipped...! Thanks Amedeo___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/chill% 40global-village.net This email sent to [EMAIL PROTECTED] -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I'm killing my database
On Apr 26, 2007, at 8:19 AM, Scott Winn wrote: When I have put a lot of data through the Importer previously I had the application crash with a SIGBUS error. I have only seen that happen in three situations (there are probably more, but this will give you a good idea): 1. Bug in JVM 2. Faulty hardware 3. Crash in native code (QT Java in my case) So, it is probably not a bug in your code. On a separate occasion, the app didn't crash, but when I went to log out I got "Internal Server Error has occurred". Looking at the run log showed three null pointer exceptions encountered; trying to dispose the editing context from the look of them (I should have saved those exception messages). Both of these problams happened in previous tests before the DB crash. That does look like a bug in your code. I would suspect your cleanup of the WOLongResponePage. I'm sure both of those incidents should raise warning flags, but I'm not sure what those flags mean. Do they point to the same problem? I found basically no information on SIGBUS errors. I can run everything through from the top and see if I have the same issues, but I think I'll try to get performance boosted a bit first. I will look into batch faulting and disposing the editing context at regular intervals. I should mention that all of this is happening on a WOLongResponse page, so a user can watch the import progress and fix any errors in the source files. That should be fine, but you have to think twice about when you clean up stuff when you start spinning off extra threads. Chuck On Apr 25, 2007, at 5:44 PM, Chuck Hill wrote: On Apr 25, 2007, at 12:03 PM, Scott Winn wrote: Thanks Chuck. I will give it a look. I still don't know what the problem was, but I have updated FrontBase and its plugin (I was a few point releases behind). The release notes for some of those points included delete fixes. I also added EC.undoManager().removeAllActions(). I haven't disposed of the editing context yet, but I may once I have checked the performance results from my most recent run. I put the same data back through the importer and no DB crash this time, That is from the FB update. although things still seemed very slow. More than 1/2 an hour to process about 1 MB of data seem like a bit much. I checked free memory just prior to doing the delete and it never dips below 74%. I have no doubt that it can be optimized more than that. Make sure you have batch faulting configured in the model. Chuck On Apr 24, 2007, at 10:32 PM, Guido Neitzer wrote: On 24.04.2007, at 20:59, Chuck Hill wrote: The first thing I would do is to add this line: recordContext .undoManager().removeAllActions(); The next thing I would do (voodoo or not) is to periodically dispose of recordContext and create a replacement. In the past that was vital. It still is. It helps. Not necessarily for performance but normally for memory usage. I normally do bulk import in batches of up to 500 objects per batch, then save and dispose the editingContext, set it to null and create in new one in the next batch. Also for bulk updating of EOs. That works well for my importers. If you need to resolve relationships during import, pre- fetching the relationships can make a huge difference. As as you are deleting, I have a DeletePrefetcher class that may be of use. I originally wrote this as a bug workaround, but it might also make the fetches more efficient. It is part of our GVCEOFExtensions framework that you can get from http:// sourceforge.net/projects/gvcsitemaker To save you the download, I have temporarily stuck a copy here: http://www.gvcsitemaker.com/chill/files/deleteprefetcher.java Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/chill% 40global-village.net This email sent to [EMAIL PROTECTED] -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscrip
Re: Un-Worder-ized Ajax framework
On 26.04.2007, at 10:18, Steven Mark McCraw wrote: 3) Consider using the frameworks. It's a few days of investment up front, but speaking as someone who was initially skeptical in adopting the frameworks in their entirety, I have to say, everything there seems really solid. It better be - there are "a couple" of people out there using the Wonder frameworks in more than one heavy load production app. cug ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Un-Worder-ized Ajax framework
Hi Ralph, I started out down the same path as yourself. Here is what I learned: 1) Don't try to get Wonder 3.0. You would think that this would be far more stable that the current build, but a recent build is the way to go (FAR more stable and complete than 3.0), especially with regard to AJAX stuff. 2) subclass ERXAjaxApplication instead of ERXApplication if you don't want to use other WOnder stuff 3) Consider using the frameworks. It's a few days of investment up front, but speaking as someone who was initially skeptical in adopting the frameworks in their entirety, I have to say, everything there seems really solid. I'm pretty heavily integrated now, and have no regrets about taking the plunge. Mark On Apr 26, 2007, at 11:57 AM, Ralph Scheuer wrote: Hello, we are currently evaluating the Ajax framework from Project WONDER. However, we do not intend to use anything else from those frameworks. Does anybody on this list have an un-WONDER-ized version of this framework or did anybody manage to get the version from WONDER 3.0 running without using ERExtensions (in particular without extending ERXSession and ERXApplication)? Thanks for any pointers. Ralph Scheuer ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/mark% 40bluecollarsoftware.com This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Un-Worder-ized Ajax framework
You can't easily remove the ERExtensions dependency, but you should be able to just link to ERExtensions without breaking anything (and ERJars). Your app should extend ERXAjaxApplication or ERXAjaxSession which is the superclass of ERXApplication and ERXSession (it only adds ajax-specific things, and none of the other wonder-y things). If you aren't even able to that, you could always steal the code from those classes, but it's much better to extend. Don't use Ajax from the 3.0 release. That's almost a year old now. You should use a recent build from the build server (http:// webobjects.mdimension.com/wonder). Wonder tends to not have "unstable" builds (per se), so using the latest build is generally a good thing. You should also join wonder-disc, which is the better place to ask this question. ms On Apr 26, 2007, at 11:57 AM, Ralph Scheuer wrote: Hello, we are currently evaluating the Ajax framework from Project WONDER. However, we do not intend to use anything else from those frameworks. Does anybody on this list have an un-WONDER-ized version of this framework or did anybody manage to get the version from WONDER 3.0 running without using ERExtensions (in particular without extending ERXSession and ERXApplication)? Thanks for any pointers. Ralph Scheuer ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/mschrag% 40mdimension.com This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Un-Worder-ized Ajax framework
Hello, we are currently evaluating the Ajax framework from Project WONDER. However, we do not intend to use anything else from those frameworks. Does anybody on this list have an un-WONDER-ized version of this framework or did anybody manage to get the version from WONDER 3.0 running without using ERExtensions (in particular without extending ERXSession and ERXApplication)? Thanks for any pointers. Ralph Scheuer ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: I'm killing my database
When I have put a lot of data through the Importer previously I had the application crash with a SIGBUS error. On a separate occasion, the app didn't crash, but when I went to log out I got "Internal Server Error has occurred". Looking at the run log showed three null pointer exceptions encountered; trying to dispose the editing context from the look of them (I should have saved those exception messages). Both of these problams happened in previous tests before the DB crash. I'm sure both of those incidents should raise warning flags, but I'm not sure what those flags mean. Do they point to the same problem? I found basically no information on SIGBUS errors. I can run everything through from the top and see if I have the same issues, but I think I'll try to get performance boosted a bit first. I will look into batch faulting and disposing the editing context at regular intervals. I should mention that all of this is happening on a WOLongResponse page, so a user can watch the import progress and fix any errors in the source files. Sincere appreciation for all the help, Scott On Apr 25, 2007, at 5:44 PM, Chuck Hill wrote: On Apr 25, 2007, at 12:03 PM, Scott Winn wrote: Thanks Chuck. I will give it a look. I still don't know what the problem was, but I have updated FrontBase and its plugin (I was a few point releases behind). The release notes for some of those points included delete fixes. I also added EC.undoManager().removeAllActions(). I haven't disposed of the editing context yet, but I may once I have checked the performance results from my most recent run. I put the same data back through the importer and no DB crash this time, That is from the FB update. although things still seemed very slow. More than 1/2 an hour to process about 1 MB of data seem like a bit much. I checked free memory just prior to doing the delete and it never dips below 74%. I have no doubt that it can be optimized more than that. Make sure you have batch faulting configured in the model. Chuck On Apr 24, 2007, at 10:32 PM, Guido Neitzer wrote: On 24.04.2007, at 20:59, Chuck Hill wrote: The first thing I would do is to add this line: recordContext .undoManager().removeAllActions(); The next thing I would do (voodoo or not) is to periodically dispose of recordContext and create a replacement. In the past that was vital. It still is. It helps. Not necessarily for performance but normally for memory usage. I normally do bulk import in batches of up to 500 objects per batch, then save and dispose the editingContext, set it to null and create in new one in the next batch. Also for bulk updating of EOs. That works well for my importers. If you need to resolve relationships during import, pre-fetching the relationships can make a huge difference. As as you are deleting, I have a DeletePrefetcher class that may be of use. I originally wrote this as a bug workaround, but it might also make the fetches more efficient. It is part of our GVCEOFExtensions framework that you can get from http:// sourceforge.net/projects/gvcsitemaker To save you the download, I have temporarily stuck a copy here: http://www.gvcsitemaker.com/chill/files/deleteprefetcher.java Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/chill% 40global-village.net This email sent to [EMAIL PROTECTED] -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
problem with delete rule (relationship)
Hello, I have two Entities entity Products have these attributes too... imgIconID imgPrindID imgLargeID ... these are foreing keys for may relation with Image entity that have ImageID fileName mimeType fileData etc... any Product have relationship to images is a To One relationship see images, is better than words http://downloads.insigno.net/help/dbimage1.jpg http://downloads.insigno.net/help/dbimage2.jpg http://downloads.insigno.net/help/dbimage3.jpg THE CASCADE RULE WORKS for all relationship: imgPrindID imgLargeID imgSchema imgMedium EXCEPT for imgIconID that is IDENTICALLY configured !!! any suggestion? I have tried to override the validateForDelete in entity Image and setting a breakpoint, semm to be totally skipped...! Thanks Amedeo ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Dynamically adding a derived attribute
it might be worthwhile to look at the Wonder source code in EOAccess/
EOControl *Utilities.java for hints. IIRC they do this on the fly for
the count* convenience methods.
On Apr 26, 2007, at 12:23 AM, Lachlan Deck wrote:
Hi there,
I'm getting tired of manually adding to each entity a
'derivedCount' attribute defined as:
{
columnName = "";
definition = "count(*)";
externalType = BIGINT;
name = derivedCount;
valueClassName = NSNumber;
valueType = l;
},
So I'm attempting to add it when the application launches
(unsuccessfully so far) whilst the entity is loading.
I think the piece of the puzzle I'm missing is how to set this
attribute as a non-class property. Any ideas?
EOEntity anEntity; // assume exists
if ( anEntity.attributeNamed( "derivedCount" ) == null ) {
EOAttribute derivedCount;
derivedCount = new EOAttribute();
derivedCount.setValueType( "l" );
derivedCount.setExternalType( "BIGINT" );
derivedCount.setName( "derivedCount" );
derivedCount.setClassName( "java.lang.Long" );
derivedCount.setColumnName( "__temp__" );
anEntity.addAttribute( derivedCount );
derivedCount.setDefinition( "count(*)" );
derivedCount.setReadOnly( true );
}
No exceptions get thrown here, however when I attempt to do a fetch
it complains about the non-existing attribute in the schema.
Thanks.
with regards,
--
Lachlan Deck
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%
40mac.com
This email sent to [EMAIL PROTECTED]
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Multiple clients in single DB
On 26 Apr 2007, at 02:33, Dave Elsner wrote: Hi, I have an WO5.3 application I want to deploy to five different clients, all have the same DB (Oracle) schema but different data. I would like to use a shared database with a new column in each table "client" that has the client ID. Then override awakeFromInsertion for all EOEntities to set the client ID and also add to the Application constructor a loop that sets an EOQualifier on each entity in the model limiting objects to the current client. Questions: * Is this the correct approach to solve this problem? (i.e not wanting to update X number of identical DB schemas every-time a change is made, keeping the data in the one location for reporting) * I tried EOEntity.setRestrictingQualifierbut that overrides any single table inheritance setup in the model. Is there away to merge two EOQualifiers? Cheers Dave My solution to this was to add a new entity Client, and make this reachable from at least one other entity bearing useful data in your schema. Via keypaths and joins, this entity should then now reachable from any entity other interesting entity. You then use EOEditingContext delegate API http://developer.apple.com/ documentation/WebObjects/Reference/API/com/webobjects/eocontrol/ EOEditingContext.Delegate.html#editingContextShouldFetchObjects (com.webobjects.eocontrol.EOEditingContext,% 20com.webobjects.eocontrol.EOFetchSpecification to examine the EOEntity for any fetch about to be carried out and to selectively amend the fetch specification's quailfier to add another EOKeyValueQualifier to achieve the required restriction. If your code carries out custom fetches which need to bypass this restriction mechanism, pass yourself a flag in the EOFetchSpecification's userInfo dictionary. This has worked very well for me in a number of apps since 1999, you don't need to tinker with EOF (everything is as per the EOModel) and all the required client ID stuff resides in a single table. -- Patrick Middleton OneStep Solutions plc 351 London Road Phone: +44 (0)1702 426400 HadleighFax: +44 (0)1702 556855 Essex. SS7 2BT Email: [EMAIL PROTECTED] England(MIME welcome) ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
