can someone tell me, how i can use "xbaseinterpreter"? I have no idea :(
I have written a DSL used to define simple protocol-structure for a sensornet, the goal of the work is to check if a data-message(as Instance) belongs to any user-defined structure. I want to use an interpret to analyze the user-defined structure and write the corresponding information into my database directly. I thought, xbaseinterpreter is just the one i can use, but i could not find much more useful information about it.
can one use the inferred JvmModel in the interpreter?How?
Thank you
See the tortoise language as a working example of how to use xbase and the interpreter.
http://eclipse.org/Xtext/documentation/208_tortoise.html
Related
I am locking for a read-write lock in Django, using PostgreSQL.
I know select_for_update
On top, I need SELECT FOR SHARE
I founds this super old Django-ticket
I couldn't find any third party library implementing this for Django
Now I am wondering:
Is there a good reason this was not implemented in the Django-ORM?
Does anyone know any third party library for this?
Or any easy work around?
Can't you wrap the logic in pl/pgsql function that uses select for share and you then call the function from django?
Is there a good reason this was not implemented in the Django-ORM?
The ticket you've posted probably provides the reason: no one is motivated enough to write a patch.
Does anyone know any third party library for this?
Not me, sorry.
And if by any chance you are thinking about ditching Django for some other ORM then you must ask yourself: "There is a feature I need that's missing in Django... what features will I miss in this other ORM?"
Or any easy work around?
Probably not. But here are some options:
Every ORM I know has an escape hatch to raw SQL. You probably know that, but reluctant to use it... But, as you also lack the motivation to make a pull request, that probably means that you do not have hundreds of requests that require SELECT FOR SHARE functionality. So you should consider it. Performing raw SQL queries
Stored procedures as steve mentioned
https://docs.djangoproject.com/en/3.0/topics/db/sql/#calling-stored-procedures
The last comment on the ticked you've posted is from a man (David Schwärzle) who claims that he has a solution (not for PostgreSQL specifically but a solution nevertheless)... maybe you should try and contact him.
Haven't tried it, but probably the way you can add the desired functionality is by Writing your own Query Expressions
You can easily implement with a raw query.
from django.db import connection
query = f"""SELECT * FROM "appname_modelname" WHERE id={obj_id} FOR SHARE"""
with connection.cursor() as cursor:
cursor.execute(query, None)
obj_id is python variable.
appname_modelname is name of table created in your db by django. Django by default combines lowercased app name and model name with underscore.
I am new to pig and writing java UDF for different operations which already exists in builtin package but the datatype does not match when called from application.
So I need to wrap pig built in functions of correct datatype from user defined datatypes.
Please suggest.
As mentioned in the comments, the solution that you propose is not possible.
Though you did not ask this (and did not provide relevant information to enable people to be more specific), it is probably possible to solve your problem with a different solution.
I am considering the use of serialize() and deserialize() for all of my data i/o due to their convenience. I do not, however, want to be stuck with unreadable files on a Julia update.
How stable are serialize() and deserialize()? Should they work between updates of 0.3? Can I expect safe behavior if I stick to basic types like arrays of Float64?
Thank you.
If you want to store data you might depend on being able to read in the future, you should not use a format that will incorporate breaking changes if/when someone finds it useful. As far as I understand the default serialization format is for network communications, so it is designed for maximum performance.
There is also the HDF5.jl package that uses a documented format and a common library that has wrappers for different languages.
I believe the official answer here is, "people will try not to break the serialization format, but you shouldn't depend upon on it."
I'm learning about SQL databases so that I can work on an existing database, and I noticed this naming convention used on a lot of the files.
I'm thinking usp stands for User Stored Procedures, but I'm not entirely certain what parmsel is for. I've tried looking this up and see others using it with the case parmSel...
So what does usp_parmsel stand for?
The files are named like so under Programmability > Stored Procedures in the SQL Object Explorer:
dbo.usp_parmsel_CustomerExists
dbo.usp_parmsel_CustomerReferral
dbo.usp_parmsel_CustomerReceipt
Thanks!
Parmsel stands for parameter selector. You can look up parameter selectors on an engine search machine.
Apparently The PARMSEL field determines the format of the remainder of the area.
There is very vague information about it online.
Maybe this? https://documentation.devexpress.com/#CodeRush/CustomDocument1524
I was finally able to verify 100% with a higher up-- it stands for Parameter Select.
I saw a few places online where this was used, it looks like a rather old naming convention-- which makes sense, I'm working with an old system.
I would like to create my own query language for a web api I wrote. But I have no idea where to start for it.
The language should be like SQL. For that I looked up the NHibernate code, cause I know, that they have the HQL (Hibernate Query Language) but it didn't help.
Are there any instructions or sth.? If this question is wrong here please move and/or tell me where I should ask else.
The first step is a lot of design work, starting be answering the following question:
Is this new Query Language going to be converted to SQL which will be
executed by a standard database engine, or are you going to write your
own database server as well?
If it's going to be converted to SQL (just like HQL) then map out the translations from your language to SQL on paper (and make sure you know the possible SQL constructs you may have to use). Once you've got that, you can start implementing it. Yes, this sounds like BDUF, but the language should be defined in one pass, I think, as it will be more consistent and easier to use if you do it that way. You can always implement it in a more Agile way once you've got that.
If you're going to write own database server, you're on your own....