,
extract it using your preferred parser, and process the data as you like.
That sounds too easy :)
i.e. what about Authentication, etc.? How to provide this in plain Java
when there's no Android.
Mit freundlichen Grüssen/Kind regards,
Martin Trummer
__
DI (FH) Martin
is it possible to use google cloud endpoints for a Java-Client?
the docs only mention mobile (Android, iOs) and Web (Java-script)
--
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To unsubscribe from this group and stop receiving emails from
On Tuesday, 13 August 2013 22:42:25 UTC+2, Jay wrote:
In my opinion, your biggest take away from this should be to avoid having
a mega entity group and you do this by simply *not* having all the
entities in question have the same parent. Or perhaps more pointedly, any
parent at all.
along those lines.
On Tuesday, August 13, 2013 7:59:52 AM UTC-5, Martin Trummer wrote:
I'm a newbie to the AppEngine datastore and like to know how to best
design this use case:
there may be some time-series with huge amount of data: e.g. terra-bytes
for one time-series
the transacations
great - thanks timh
that was the point, I was missing!
Mit freundlichen Grüssen/Kind regards,
Martin Trummer
__
DI (FH) Martin Trummer
Mobile: +43 676 700 47 81
skype:ds.martin.trummer
mailto:martin.trum...@dewesoft.com
*Attention! New mailaddress ends with .**com
I'm a newbie to the AppEngine datastore and like to know how to best design
this use case:
there may be some time-series with huge amount of data: e.g. terra-bytes
for one time-series
the transacations
dochttps://developers.google.com/appengine/docs/java/datastore/transactionssays
about entity
costs.
How *YOU* bill your customer does not have to be locked to how Google
bills you, only structured so it covers the costs and scales properly.
On Tuesday, April 9, 2013 11:07:27 AM UTC-5, Martin Trummer wrote:
unfortunately a flat rate cannot be used, as we expect users to be very
unfortunately a flat rate cannot be used, as we expect users to be very
different:
e.g. we might have big companies with several users that belong to one
billing-user and this billing-user would need several TB per month and
a lot of CPU time
and on the other end of the scale we could have a
Any ideas to this?
Or should I really make one application per user?
I think this could really be a nightmare when upgradin? Or is there some
way to automatically update e.g. 1000 instances?
On Wednesday, 4 July 2012 16:49:54 UTC+2, Martin Trummer wrote:
If I write an application
If I write an application on AppEngine that supports multiple users, I'll
get a bill at the end of the month for the complete app, right?
Is it somehow possible to break down this cost to a per-user basis?
i.e. I'd like to know which of my logged-in users has caused how much of
the total cost?
is it somehow possible to break-down the billing into users that have
logged in to my application?
e..g. users can log-in with their gmail account, upload data, do
calculations, etc.
at the end of the month, I'll get one bill from google.
is there a way how I can break-down this bill to the
just a guess:
An index only contains entities that have every property referred to
by the index.
http://bit.ly/qiTBk
that my be the reason, why you get a different number of results
On Nov 6, 6:53 pm, Adhi adhi.ramanat...@orangescape.com wrote:
Yes, I've tried using order by also. But its
the paragraph When_to_Use_a_Memory_Cache of the docu explains it
well:
http://bit.ly/3LMsR9
On Oct 30, 11:11 pm, loell loellanth...@gmail.com wrote:
sorry to get back at this discussion so late, but i have another
question in relation to this behavior / operation, so how would one
you cannot use memcache to reliabliy increment the counter - it's just
a cache and thus there's no such thing like a transaction (AFAIK)
the memcache only makes sure, that a single put and get are atomic
the problem arises in this case:
2 users call the same servelt, but these 2 calls will not
short,
human-readable strings, however, I will be happy to amend the article with
this caveat.
Regards,
Nick Johnson
On Sun, Oct 25, 2009 at 5:40 PM, Martin Trummer martin.trummer...@gmail.com
wrote:
in this article
http://code.google.com/intl/de-DE/appengine/articles/paging.html
On Oct 27, 10:53 am, Nick Johnson (Google) nick.john...@google.com
wrote:
Collision attacks on MD5 have been found, yes. But a collision attack
requires the attacker to specify both strings, and currently at least,
requires them to be at least 128 bytes long, and makes no guarantee about
in this article
http://code.google.com/intl/de-DE/appengine/articles/paging.html
the author points out the problems that arise when you use a field
that may not be unique for paging.
the solution is to use a sharded counter over the user to make the
field unique.
Very fine until here.
But then
17 matches
Mail list logo
