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> 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) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com > > This email sent to aa...@chatnbike.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
