Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would go for a common interface and a common parent class, and possibly use the builder pattern also..;</p> <pre><code>a common partialFooBar interface a common fooBarChimera parent class </code></pre> <p>You could then potentially put your converter into the fooBarChimera parent (and enforce the required extra details for the finalisation of whichever you want.</p> <p>You may also want to use the builder pattern.</p> <p>to flesh it out a bit...</p> <p>ie the first class </p> <pre><code>partialFooBarBuilder </code></pre> <p>has a simple default constrcutor and setter methods.</p> <p>The final method will then 'convert' this class to the 'full blown' version, or the fooBarChimera, which then only needs to have 'getter' methods in it.</p> <p>The proper version is only available from this builder class (or the fooBarChimera), so you can more easily enforce that the contents are in good shape before returning your final proper foo class (you can do this with some nice error handling if it is linked to your user interface).</p> <p>so you end up with somthing like...</p> <pre><code>public class buildpartFooBar implement fooBarCommon{ //fooBarCommon is the interface the enforces the commonality of between the 2 objects. public buildPartFooBar(){...} ...[various setter methods here ....] //make the different types of object we may become private foo1 makeFoo1(iNeedThisToBeAFoo1 object){...} private foo2 makeFoo2(iNeedThisToBeAFoo2 object){...} private bar1 makeBar1(iNeedThisToBeABar1 object){...} private bar2 makeBar2 (iNeedThisToBeABar2 object){...} private fooBarChimera makeChimera (){...} </code></pre> <p>}//end of buildPartFooBar class</p> <p>It is then simple to include a method makeFooFromBar, where you return a foo1 or Foo2 or whatever you like, you will likely do this via a static method in your fooBarChimera class</p> <p>Remember that you will need to deal with the situation that your converted bar and foo clases are related to one another (you may need to implement some form of collection that has a bar key and foo object, or maybe this should be implemented in your fooBarChimera somewhere).</p> <p>You may decide that foo and bar also need comparable methods such as, again it may be sensible to include these in the fooBarChimera as a static comparison. This way you only need to write it once in the parent.</p> <p>couldThisFooBeBar</p> <p>and </p> <p>couldThisBarBeFoo</p> <p>so as at creation time you can compare them and decide if they should be linked automatically, then saving you the operation of conversion if the link already exists in your collection.</p> <p>You will also need to decide if the conversion is 2 way, a foo can be a bar, but a bar may be compatible with 2 foos.</p> <p>In this case you may decide to head over to a database that can handle this sort of thing and store your foo and bar objects in it, it may be easier than a customised colection class also, especially if you give each foo and bar a uniquie objectID (guid).</p> <p>It could become a lot more advanced.... it depends where you intend to take it, sounds like an interesting task you have set yourself, can we ask why you want to do this?</p> <p>something I might just do for fun.... like when I modelled a legacy DB in terms of java collections, only to realise how stupid I was, and just converted it to a more sensible DB instead.</p> <p>David</p>
    singulars
    1. This table or related slice is empty.
    1. POconverter between different Java types
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDaveM
    1. USDaveM
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POconverter between different Java types
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COIt seems like a very good idea and start point and i'll try to implement it this way. Thanks a lot! The reason I need it is to convert few different DB tables records to one type object because later i need to do a lot of calculation on a collection of this object.
      singulars
      1. PO
      1. USDiSol
    2. COEven better / easier, can you get an sql select script to join the required tables together, then model a java class on that info. The java class could even have a link to a public static (ie non modifiable) SQL select statement (that should probably be a stored procedure) that can rerun your query at desired intervals (or you can get your DBMS to do that for you, and back it up via your java class. Thanks for accepting the answer.
      singulars
      1. PO
      1. USDaveM
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload