Skip to Main Content

Java Programming

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

general approach to implementing multiple color name dictionaries?

RichFNov 11 2010 — edited Nov 15 2010
My [url http://r0k.us/graphics/SIHwheel.html]interactive color wheel applet currently has a single class providing names and hex values for over 1500 colors. I am considering offering multiple of these "color name dictionaries" (CNDs) -- the current set, Munsell colors, Sherwin Williams colors, etc.. Each dictionary element consists of a hex string providing the color value, and a name string. There are at least 3 approaches which might be possible:

1) store each CND in its own plain text file with file names ending in common extension, such as ".cnd". At run time, hunt for .cnd files in current directory and build a GUI selection list dynamically. This would likely be my approach in other languages, and would save space in the jar file. (One byte per character instead of two.) But I do not even know if an applet can read files in its own .jar. If it can, they would be in the current directory, right?

2) store each CND in its own class. Is there a way to just drop classes into a project, and have the java parent automatically recognize what CND classes there are and adjust the GUI to support it/them?

3) store all CNDs in one class, as separate 2-d arrays. It could end up as a huge class (the current class, with just one dictionary, is 78k in size), but might be the simplest to implement.

Which path would you take? Is there a better way that I haven't thought of?
This post has been answered by Kayaman on Nov 15 2010
Jump to Answer

Comments

MaxOrgiyan-Oracle

Hi Mark,
Unless you have a specific need to shred the JSON document into relational columns, it's best to keep it intact. The advantage is that you get schema flexibility - as the application changes, you can add or remove fields in your JSONs as needed, without having to alter tables to add/remove new relational columns. Also, you get to store the data in its original format (i.e. JSON), and then you can also ship it out in the same format.
The recommended storage column is BLOB (as opposed to CLOB) on database releases below 21c. On database release 21c (currently only available on autonomous free tier), there's a new Oracle type for JSON specifically, called JSON type.
There are a bunch of different operators that allow you to query JSON data from SQL, such as json_value, json_query, json_table, and so on. For examples, see here.
Which 12c version are you on? The JSON support mentioned above was introduced in 12c, and there have been many bug fixes since that release. It's best to upgrade to a more recent release for JSON usage, if at all possible. 19c is best, as it's a long term release and has all the bug fixes.
Other things that might be of interest:
(1) SODA API. These are the JSON NoSQL style APIs for Oracle Database, implemented in various languages (Java/node.js/python, and built into ORDS). They allow you to work with JSON in Oracle in a very easy way, without using SQL.
(2) Autonomous JSON cloud service. This is all of the above, on the cloud. There's a free tier version you can use to play with it.
Let us know if you need more info.
Thanks,
Max.

1 - 1
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Dec 13 2010
Added on Nov 11 2010
21 comments
408 views