Is it possible to use a database sequence for a non-PK field in a Grails app? - database

In my application i need a unique value for a specific field in the database. This field has to be of type Integer. So i was wondering if it is possible to use a sequence for the field? And how to i implement that in my GORM domain class?

See the grails doc on how to use sequences. Depending on the source of the sequence ( (oracle/postgres) sequence number generator type / database table)
static mapping = {
intField1 generator:'sequence', params:[sequence:'sequence_name']
intField2 generator:'sequence', params:[table: 'hi_value', column: 'next_value', max_lo: 100]
}

Related

Composite or FilterPredicate query on Ref'd entity

Here's what I have:
class A{
Ref<foo> b;
Ref<foo> c;
int code;
Date timestamp
}
The pseudo "where" clause of the SQL statement would like like this:
where b = object or (c = object and code = 1) order by timestamp
In plain English, give me all the records of A if b equals the specific object or if c equals the specified object when code equals 1. Order the result w/ timestamp.
Is the composite query part even possible w/ datastore (Objectify)? I really don't want to do two queries and merge the results, because I have to sort by timestamp.
Any help is appreciated.
P.S. I already tried
new FilterPredicate(b, EQUAL, object)
This didn't work, because the entity type is not a support type.
Thanks!
Pass a native datastore Key object to the FilterPredicate. The Google SDK Key, not the generic Objectify Key<?>.
Normally when filtering on properties, Objectify translates Ref<?> and Key<?> objects to native datastore keys for you. With the google-supplied FilterPredicate, that isn't an option. So you have to do the translation manually.
Objectify stores all Key<?> and Ref<?> fields and native datastore Keys, so you can freely interchange them (or even change the type of fields if you want).

Database design for variable number of attributes

I am trying to come up with a schema for an Oracle db. The problem is as follows:
The database should represent an attribute (- say a url) associated with a variety of attributes for a variety of values.
For Example:
The database should have the mapping:
If attribute-X has value-X ==> Url-X
If attribute-Y has value-Y ==> Url-Y
If attribute-X has value-X && attribute-Y has value-Y ==> Url-XY
Also the number of attributes is not defined, so these cannot correspond to a attribute in the db.
The workaround I have thought is to store it as a multi name value-pair and use the same to look up in the database.
For example:
**attribute** **Key** **Value**
attribute-X value-X Url-X
attribute-Y value-Y Url-Y
attribute-X&attribute-Y value-X&value-Y Url-XY
I am new to databases and I am aware that is is not a neat representation of the data model. Is there a better way to represent this ?
You could model this with one table, but then you would need to keep adding attributes (new column for each new attribute), which is not a good design.
You can however, model this so you can add attributes types, then add the attribute dynamically.

cakephp setting select options and values at Model

In my database model, my attribute is set as type INT.
On the front end, I want to display a select field with representative values for the respective Integer values.
eg: [1 = Home, 2 = About]
I am currently using an external plugin for the administrating content, and the select values only allows integer. So my idea is to achieve this at respective Model. Is it possible?
Genarally yes.
You should be able to attach results of Model->find('list') to select field. Of course your model should have name or title fields for description values (Home, About).
Sounds like the kind of enum representation as I always use.
Try this solution:
http://www.dereuromark.de/2010/06/24/static-enums-or-semihardcoded-attributes/
I basically uses an array matching to resolve those ints into strings in a clean way - using the model. can be the whole array for select fields or just the specific string for output in the view/index.
Its also fully form and bake-template capable.
If you name the field "attribute" in your table, and name the method "attributes()" you can easily have "cake bake" to bake this via custom templates.

In a Big Table, is it normal to key values in child (sub) collections?

I'm using Google App Engine and thus Big Table.
I have a person entity that looks like this:
{
// This property would be encoded into JSON and saved un-indexed as db.Text()
phone_numbers:
{
'hHklams8akjJkaJSL': // <-- Should I key this object?
{
number:'555-555-5555',
type:'mobile',
},
etc...
},
// This property is an array of strings.
// It is searchable so that a query could be run to find all
// people with a particular phone number:
// "SELECT * FROM person WHERE phone_number_search_property =
// '5555555555'"
phone_number_search_property:['5555555555','other phone numbers...'],
first_name:'...',
etc...
}
The phone_number property is stored as a blob of unindexed text in JSON format (db.Text). If I want to refer to a particular phone number in this situation, I decode the json, then get the phone number with the particular key that I am looking for.
The phone_number_search_property is used for searching. It enables a search by phone number: "SELECT * FROM person WHERE phone_number_search_property = '5555555555'"
What is a good way to refer to a phone number inside of an entity in this situation? Here, I have each value keyed using a UUID. Is this a "normal" and accepted way of doing things? If not, what is?
Thanks!
If data object is really just part of another object and is never accessed without the "parent" object (as is the case with phone number and person) then IMHO it's ok to serialize it and store it inside the "parent" object. So what you did is OK.
You search persons by phone number, so the solution to have additional property with (normalized) phone numbers is working. If you'd need to search on additional property, then it would not work (e.g. limiting search to only mobile numbers).
Why do you key serialized phone numbers by a hashed string (I assume you generate it via UUID.fromString(String))? Just use the (normalized) phone number - it is unique.

store strings of arbitrary length in Postgresql

I have a Spring application which uses JPA (Hibernate) initially created with Spring Roo. I need to store Strings with arbitrary length, so for that reason I've annotated the field with #Lob:
public class MyEntity{
#NotNull
#Size(min = 2)
#Lob
private String message;
...
}
The application works ok in localhost but I've deployed it to an external server and it a problem with encoding has appeared. For that reason I'd like to check if the data stored in the PostgreSQL database is ok or not. The application creates/updates the tables automatically. And for that field (message) it has created a column of type:
text NOT NULL
The problem is that after storing data if I browse the table or just do a SELECT of that column I can't see the text but numbers. Those numbers seems to be identifiers to "somewhere" where that information is stored.
Can anyone tell me exactly what are these identifiers and if there is any way of being able to see the stored data in a #Lob columm from a pgAdmin or a select clause?
Is there any better way to store Strings of arbitrary length in JPA?
Thanks.
I would recommend skipping the '#Lob' annotation and use columnDefinition like this:
#Column(columnDefinition="TEXT")
see if that helps viewing the data while browsing the database itself.
Use the #LOB definition, it is correct. The table is storing an OID to the catalogs -> postegreSQL-> tables -> pg_largeobject table.
The binary data is stored here efficiently and JPA will correctly get the data out and store it for you with this as an implementation detail.
Old question, but here is what I found when I encountered this:
http://www.solewing.org/blog/2015/08/hibernate-postgresql-and-lob-string/
Relevant parts below.
#Entity
#Table(name = "note")
#Access(AccessType.FIELD)
class NoteEntity {
#Id
private Long id;
#Lob
#Column(name = "note_text")
private String noteText;
public NoteEntity() { }
public NoteEntity(String noteText) { this.noteText = noteText }
}
The Hibernate PostgreSQL9Dialect stores #Lob String attribute values by explicitly creating a large object instance, and then storing the UID of the object in the column associated with attribute.
Obviously, the text of our notes isn’t really in the column. So where is it? The answer is that Hibernate explicitly created a large object for each note, and stored the UID of the object in the column. If we use some PostgreSQL large object functions, we can retrieve the text itself.
Use this to query:
SELECT id,
convert_from(loread(
lo_open(note_text::int, x'40000'::int), x'40000'::int), 'UTF-8')
AS note_text
FROM note

Resources