Chuck, thanks a lot, sounds hopeful :)
Will check. Should you happen to have a link to some sample code at hand, I'd be grateful; otherwise of course I'll search for it myself :) Thanks again, OC > On 7. 6. 2020, at 8:06 PM, Chuck Hill <hill.ch...@gmail.com> wrote: > > I think what you want is to subclass EOAadptor, EOAdaptorChannel, and > EOAdaptorContext and have them talk to your Java classes. The layer above > (EODatabase etc) can stay are they are. > > There have been flat file adataptors, screen scrapers etc. I don’t see why > what you want could not work. The model the entities are in control the > EOAdaptor used. > > Chuck > > >> On Jun 7, 2020, at 10:02 AM, Aaron Rosenzweig via Webobjects-dev >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> wrote: >> >> Hi OC, >> >> I suppose you could move your java POJOs into a .jar and then expose them >> with a java app running on a particular port that masquerades as a DB >> endpoint. I’m not sure it’s worth the trouble but it could be done. This >> would be the “my DB in a box” solution where you essentially make trimmed >> down DB server that doesn’t allow updates but allows SQL queries. It gets >> weird though with EOF and honestly I’ve never tried jumping DBs for foreign >> keys. I’ve only used multiple DBs to do queries on unrelated data. >> >> I assume you like how handy it is to have the java classes at your finger >> tips and able to edit them when needed but you also like to be able to query >> in SQL for various attributes that those POJOs have… so you go to the >> trouble of making an EO doppelgänger that you have to sync. >> >> Perhaps you can make your POJOs enums? If that’s feasible then you could use >> the enum prototype in your EO so that instead of having an FK it is an >> attribute of an enum type. >> >> If enums are not feasible then maybe you should stop thinking of them as >> POJOs and make them EOs which you have to change via SQL migrations instead >> of twiddling java classes. That would be the path of least resistance. Since >> they are pretty much read only, you could consider making them shared Eos >> but it’s not mandatory to do so. >> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 >> >> >>> On Jun 7, 2020, at 12:37 PM, ocs--- via Webobjects-dev >>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>> wrote: >>> >>> Hi there, >>> >>> let me please ask another weird question. For the context, thing is, one of >>> our applications supports “predefined” EOs -- things like static lists and >>> similar. In our case, they are completely defined in the Java code -- the >>> number of them, all their attributes, whatever. Then, runtime, they are >>> shared for all users/sessions/editing contexts. >>> >>> Since they need to be real EOs (they mix with normal dynamically defined >>> objects, they are part of relationships, etc), it brings non-trivial >>> problem how to implement the stuff. >>> >>> At this moment, we >>> - at launch, synchronise these objects into the database: if the Java code >>> defines a new object which has not been there, it is inserted; if there are >>> changes in attributes, they are updated. If an object of this kind is found >>> in the database and there's no description for it in the Java code, it is >>> deleted; >>> - then we load them into the shared EC for all users to share them. >>> >>> It works, but the synchronisation approach is ugly; it feels sort of wrong >>> to keep copies of those static objects in the database. >>> >>> Now, I wonder: EOF does support multiple data sources. How difficult and >>> error-prone would it be to implement my own data source, which would -- >>> instead of from a DB -- “load” objects from the application predefined >>> code? Would it be possible? Wouldn't it bring more problems than the old >>> code did? To illustrate the idea, here's the notorious Apple pic, tweaked >>> appropriately: >>> >>> <canThisBeDone.jpg> >>> Has anybody out there already tried something like that, and if so, with >>> any luck? >>> >>> Thanks, >>> OC >>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>> <mailto:Webobjects-dev@lists.apple.com>) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >>> >>> <https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com> >>> >>> This email sent to aa...@chatnbike.com <mailto:aa...@chatnbike.com> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com >> >> <https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com> >> >> This email sent to hill.ch...@gmail.com <mailto:hill.ch...@gmail.com>
_______________________________________________ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
